To support the increase in available APIs, credentials are stored centrally and secretly and are encrypted in the Oomnitza vault. The Oomnitza vault is based on the HashiCorp implementation of the vault.
The advantages of using a vault are:
- Easier to set up new custom integrations and API workflows
- Easier to authenticate and execute APIs that are owned by different groups in an organization
- Easier to prevent secrets sprawl
Adding credentials to the vault
Only users whose role has has been granted read and write access can add credentials.
Vendor's application is listed
The type of authorization determines the type of information that you need to provide to authenticate with the vendor's application.
- Click Configuration>Security>Credentials.
- Click Add new credential +.
- Select the vendor's application.
- Click the right arrow .
- Enter the name of the credentials. To easily identify the application that the credentials are associated with, specify the application name, level of access, and authorization type such as Okta Read-Only API Key.
- Enter the credentials.
- Click CREATE.
Vendor's application is not listed
- Click ADVANCED MODE.
- Enter the name of the credentials.
- Enter the owner of the credentials.
- Click AUTHORIZATION.
- Select the type of authorization.
- Enter the credentials.
- Click CREATE.
Types of authentication
The vault currently supports the following types of authentications:
- API key. API key is be used for token-based authentication where you're provided with a single credential such as an API key, an API token, or a static token.
- AWS Auth. AWS Auth is a special type of authentication that is used for integrations with Amazon Web Services (AWS), including retrieving AWS Users and AWS EC2 instances.
- Basic Auth. Basic Auth is used for username and password authentication.
- Custom O Auth 2.0. You can use OAuth when you add credentials for custom extended integrations for assets.
- OAuth 2.0. OAuth 2.0 authorization is used to enable applications to obtain limited access to user accounts for an HTTP service, such as Google, Salesforce, and Zoom.
- Session-based. Session Based authentication is used to create a Session ID, which is used to authenticate every subsequent outgoing request.
- Signed request. Signed Request authentication is used to create a unique digital signature, which prevents tampering with a request while it's in transit.
Because the authorization flow varies between vendors, Oomnitza provides a set of preset systems that we've configured to use OAuth 2.0, Session-Based, or Signed Request authentication. If you have a system that requires this authentication, and it is not available in the list, contact support@oomnitza.com.
Adding another layer of authentication with mTLS
When interacting with certain APIs, you may be required to enable mutual TLS (mTLS). mTLS enhances security by encrypting communications between the client (your Oomnitza instance) and the server (the external API).
For most communications, standard authentication provides sufficient protection. This level of authentication is only used on top of standard authentication and may be required by certain APIs such as Amazon Web Services (AWS) and Google Cloud.
For information on how mTLS works, see Cloudfare:Mutual TLS.
Prerequisites
1. Existing credentials
Ensure your credentials and credential details are populated in the INFORMATION and AUTHORIZATION tab.
2. Certificate and private key, or a single .pfx file:
Certificate (formats: *.crt
, *.cert
, *.der
, *.pem
, *.p7b
, *.p7c
, or *.cer
): Contains your public key and identity information, certified by a trusted authority.
Private Key (formats: .key
, .pem
): Contains a secret key, used to decrypt data and for signing your communications.
.pfx
or .p12
files: Bundles your certificate and private key, offering a convenient single-file solution.
3. Certificate password
This password is required for password-protected certificates, typically used in conjunction with .pfx
or .p12
files. It is used to decrypt the certificate, enabling its use in secure communications.
Procedure
- Navigate to the CERTIFICATES tab in ADVANCED MODE.
- Enable the Use mTLS option.
- Choose your certificate type. If your certificate file is password-protected, enter the password.
- Click CREATE
Applying vault credentials
When the credentials for vendor applications are added to the vault, you can reference them in various places such as in API blocks and SaaS User Role blocks in workflows as well as in extended asset and user integrations.
For OAuth credentials, the expiration date is read-only and is retrieved from the connected system. For all other authentications, the expiration date must be entered manually.
How the credentials are stored
The Oomnitza vault is integrated as a separate service in each Oomnitza instance. The implementation is based on Hashicorp Vault, which is the industry standard for encrypted secret storage. Secrets are stored in the database as encrypted strings that can only be accessed by the application server in the same subnet.
Comments
0 comments
Please sign in to leave a comment.