Accounts

Learn more about what accounts are and how they are used within the Digibee Integration Platform.

Accounts play a critical role in ensuring the security of authentication processes and the storage of sensitive data such as passwords, private keys, and authentication tokens by encrypting the data. These accounts can be used in connectors in integration flows to verify access to endpoints.

To access the Accounts page, click Settings in the upper right corner of the Platform home page and open the Accounts submenu.

Accounts basic information

There are several types of Accounts available, including AWS V4, Basic, Public Key, Secret Key, OAuth 2, and API Key. These Accounts can be configured and stored with the Store Account connector without interrupting execution, which increases the flexibility and security of the integration process.

Accounts type

As we have seen, there are many different types of accounts that meet different integration needs. Here we give you a simple overview of each of these Account types.

Learn more about the configuration details for each account type in the Configuring each account type documentation.

• API Key: API key accounts specify an API Key to be used in endpoints that require an API Key.

• Basic: A Basic Account is a simple, traditional form of authentication where you provide a username and password.

• Custom Auth Header: This type of account is used when an endpoint requires a custom authentication header.

• OAuth Bearer: Select this type of account when you need to store an OAuth token. The token is assigned to the "Authorization" parameter in the request header.

• Private Key: Account type that stores a private key.

• Public Key: Public Key Accounts are used for secure authentication using public-private key pairs to increase security during integrations.

• OAuth 2: OAuth 2 Accounts enable integration with services that use OAuth 2.0 for authorization, adding an extra layer of security to the process.

• Certificate Chain: Specifies a chain of certificates. It's used for endpoints that require 2-way SSL authentication or a certificate from the client. The certificate chain must be specified in the correct order and in pem format. To convert your key, you can do it through OpenSSL via the command line, e.g: openssl pkcs12 -in mycert_xpto.p12 -out myapp.pem

• Secret Key: Secret key accounts are used for encryption connectors.

• Google Key: Service key for accessing Google APIs.

• Kerberos: Account that stores the Keytab for authentication in environments that use Kerberos.

• AWS V4: This Account type is specifically designed to interact with Amazon Web Services (AWS) using version 4 of the AWS Signature.

• OAuth Provider: Account used for authorization via the OAuth pattern, which is normally used for logging in to web applications. It can only be used for the Salesforce connector
• SMTP Auth And Properties: This account is used only for Mail Connector. It sets the credentials for the SMTP server to send emails.

• NTLM: NTLM (NT Lan Manager) is a set of Microsoft security protocols for authentication, integrity, and confidentiality that you can access through the SOAP V3 connector.

A vulnerability has been identified in NTLM due to the use of outdated encryption algorithms, such as DES and RC4, which have known cryptographic weaknesses. These technologies make communication more vulnerable to attacks, for example, brute force and Pass-the-Hash. We recommend disabling NTLM whenever possible, replacing it with more secure protocols like Kerberos, and implementing advanced security policies to mitigate the risks.

• AWS Role: This account is designed to contain the information of an AWS role that will be assumed by an AWS user. It must always be used together with an AWS V4 account type. If set correctly, the connector ensures that the user of the AWS V4 account assumes the role of the AWS Role and then accesses the AWS service with temporary credentials. The AWS Role can currently only be used in the DynamoDB connector.
• Azure Key: Account used to connect to Azure Key Vault services on Microsoft Azure.

Expiration date for accounts

For some account types for which the external service provides an expiring validation for the credentials, you can add an Expiration date as a reminder. With this configuration, the accounts whose credentials are one month from expiration are tagged with Expires in DD/MM. Accounts for which the expiration date has already passed are tagged with Expired.

The account types that you can configure an expiration date are:

• OAuth Bearer

• Private Key

• Public Key

• OAuth 2

• Certificate Chain

• Google Key

• AWS V4

The expiration date must be entered in the Date field in the format DD/MM/YYYY, for example 30/05/2030 for May 30, 2030. This field is optional and you can edit it at any time.

Note that Digibee is not responsible for the expiration of account credentials, this accountability lies with the external service. Account credentials will expire only on the configured expiration date if the date matches that of the external service. In such cases, the account will stop working in the associated pipelines and you will need to review the credentials and redeploy the associated pipelines. Otherwise, the account will continue working normally.

You can use the Close to expiring and Expired filters in the search bar on the Accounts page to filter for accounts that are about to expire, have already expired, or both.