Vault Service (Cloud)

Omada Identity Vault Service is designed to help companies using Omada Identity to comply with zero trust policies and align Omada Identity with the security challenges encountered in dynamic cloud-based infrastructures.

Vaults are central, secure places which store and manage the secrets (for example, API keys, passwords, and certificates) that an application needs in order to work with other applications and services, and provide secure access only to authorized resources.

Instead of having Omada Identity storing sensitive information locally, the Vault Service is able to fetch secrets from vaults when:

• Onboarding a system and editing the connection details
• The connection details are pushed to Omada Provisioning Service
• Omada Data Warehouse is pulling the data connection details
• On-prem Setting up the sending of mails
• On-prem Setting up log configuration

note

The Vault Service only covers HashiCorp Vault and Azure Key Vault, in relation to the onboarding system functionality. Other vendors vaults, like for example CyberArk's, are not supported.

Create a connection to a vault

warning

You can only connect to a cloud-based instance.

To create a connection to vault:

1. Go to Administration > System settings > Vault connections.

2. Click New.

3. Name your vault connection object.

4. The Onboarding values field contains the relevant XML schema of your vault provider. Find how to build this XML according to your vault here:

   • HashiCorp Vault

     • Parameters

       • Name - enter the secret engine supported: HashiCorpKV2.
       • Authmethod - VaultToken, AzureAD, or AzureMI
         • Token authentication should not be used in a production environment. For proper security, set it up using AzureAD or AzureMI authentication.
       • X-Vault-Token - used for VaultToken authentication.
       • ClientID - the service principal's object ID is known as its client ID and acts like its username.
       • TenantID - Microsoft Entra ID tenant ID that should be used for authenticating requests to the key vault.
       • ClientSecret - the service principal's client secret acts like its password.
       • Scope - OAuth 2 scope
       • Role - role created in HashiCorp.
       • Uri - Uri of the HashiCorp Vault Service
       • Path - the path where the secret engine is enabled. For more information, refer to the HashiCorp documentation.
       
       
       On-prem Example with VaultToken authentication

       <?xml version="1.0" encoding="utf-8"?>
       <ConfigurationParameters xmlns="http://schemas.omada.net/ois/2016/SystemConfigurationValuesML">
       <configurationParameter Name="Name">
           <values>
               <value>HashiCorpKV2</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="AuthMethod">
           <values>
               <value>VaultToken</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="X-Vault-Token">
           <values>
               <value>...</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="Uri">
           <values>
               <value>[base address of the vault service you are connecting to]</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="Path">
           <values>
               <value>[path to secret engine]</value>
           </values>
       </configurationParameter>
       </ConfigurationParameters>

       Example with AzureAD authentication

       <?xml version="1.0" encoding="utf-8"?>
       <ConfigurationParameters xmlns="http://schemas.omada.net/ois/2016/SystemConfigurationValuesML">
           <configurationParameter Name="Name">
               <values>
                   <value>HashiCorpKV2</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="AuthMethod">
               <values>
                   <value>AzureAD</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="ClientId">
               <values>
                   <value>!Client ID goes here!</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="TenantId">
               <values>
                   <value>!Tenant ID goes here!</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="ClientSecret">
               <values>
                   <value>!ClientSecret ID goes here!</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Scope">
               <values>
                   <value>!Application scope goes here!</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Role">
               <values>
                   <value>dev-role</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Uri">
               <values>
                   <value>https://{vault-name}</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="path">
               <values>
                   <value>secret</value>
               </values>
           </configurationParameter>
       </ConfigurationParameters>

       On-prem Example with AzureMI authentication

       <?xml version="1.0" encoding="utf-8"?>
       <ConfigurationParameters xmlns="http://schemas.omada.net/ois/2016/SystemConfigurationValuesML">
           <configurationParameter Name="Name">
               <values>
                   <value>HashiCorpKV2</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="AuthMethod">
               <values>
                   <value>AzureMI</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Role">
               <values>
                   <value>dev-role</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Scope">
               <values>
                   <value>{application scope}</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="Uri">
               <values>
                   <value>https://{vault-name}</value>
               </values>
           </configurationParameter>
           <configurationParameter Name="path">
               <values>
                   <value>secret</value>
               </values>
           </configurationParameter>
       </ConfigurationParameters>

     • Resources

       The Vault Data Connection for HashiCorp Vault needs to contain the properties that are described in the Azure Auth login request

       • https://www.vaultproject.io/api-docs/auth/azure#login

       • https://www.vaultproject.io/docs/secrets/k

       Please refer to HashiCorp documentation for more information:

       • https://www.vaultproject.io/docs/auth/azure

       • https://learn.hashicorp.com/tutorials/vault/getting-started-first-secret

   • Azure Key Vault

     • Parameters

       • Depending on the authentication method chosen, the number of parameters in the XML schema for the vault connection might vary:

         Parameters	Microsoft Entra ID	Azure MI
         Name	AzureKeyVault	AzureKeyVault
         Authmethod	Microsoft Entra ID - Microsoft Entra ID access tokens that may be obtained using OAuth2. When using AzureKeyVault with AzureAD Authentication,ensure that the AzureAD Application Service Principal has the Key Vault Reader and the Key Vault Secrets User role assignment on the AzureKeyVault resource. For more information, refer to the Azure documentation.	Azure MI - Azure Managed Identities
         ClientID	AzureAD Client Id - the service principal's object ID is known as its client ID and acts like its username.	Optional
         TenantID	AzureAD Tenant Id - Microsoft Entra ID tenant ID that should be used for authenticating requests to the key vault.	n/a
         ClientSecret	AzureAD Client Secret - the service principal's client secret acts like its password.	n/a
         Scope	https://management.azure.com/	n/a
         Uri	The URI to allow the applications to retrieve specific versions of a secret: https://{vault-name}.vault.azure.net

   XML schema with Microsoft Entra ID authentication

   <?xml version="1.0" encoding="utf-8"?>
   <ConfigurationParameters xmlns="http://schemas.omada.net/ois/2016/SystemConfigurationValuesML">
       <configurationParameter Name="Name">
               <values>
                   <value>AzureKeyVault</value>
               </values>
           </configurationParameter>
       <configurationParameter Name="AuthMethod">
           <values>
               <value>AzureAD</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="ClientId">
           <values>
               <value>!ClientID value goes here!</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="TenantId">
           <values>
               <value>!TenantID value goes here!</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="ClientSecret">
           <values>
               <value>!ClientSecret value goes here!</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="Scope">
           <values>
               <value>!Scope goes here!</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="Uri">
           <values>
               <value>https://{vault-name}.vault.azure.net/</value>
           </values>
       </configurationParameter>
   </ConfigurationParameters>

   XML schema with Azure MI authentication method

   <?xml version="1.0" encoding="utf-8"?>
   <ConfigurationParameters xmlns="http://schemas.omada.net/ois/2016/SystemConfigurationValuesML">
   
       <configurationParameter Name="Name">
               <values>
                   <value>AzureKeyVault</value>
               </values>
           </configurationParameter>
       <configurationParameter Name="AuthMethod">
           <values>
               <value>AzureMI</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="ClientId">
           <values>
               <value>!ClientID value goes here - optional!</value>
           </values>
       </configurationParameter>
       <configurationParameter Name="Uri">
           <values>
               <value>https://{vault-name}.vault.azure.net/</value>
           </values>
       </configurationParameter>
       
   </ConfigurationParameters>

   For more information, refer to the Azure documentation.

5. Click Save.

6. Click Test connection to verify the vault connection.

info

When the system administrator creates or modifies the Vault Connection, the connection is tested through a call to the Omada Vault Service API to make sure that the service can connect and authenticate.

Create a vault secret

To create a vault secret:

1. Go to Administration > System settings > Vault secrets.

2. Name the vault secret.

3. In the Vault connection field, select the data object created in Vault connections.

4. Enter the Path to the secret on the vault.

5. Optionally (if the secret is a part of a JSON object or a dictionary object), enter a Key to the secret.

6. Check Test connection to validate the vault connection, path, and key.

7. Click OK.

Onboard a system with a vault secret

To onboard a system with a vault secret:

1. Go to Setup > Master Data > Systems.

2. Select the relevant registered system.

3. In the System definition section, click Connection details.

4. In the dialog, click the icon Vault configuration next to the Password field.

5. When the dialog opens, select the vault secret object.

6. Check Test connection to validate the vault, path, and key.

7. Click Save.

8. In the parent dialog, the Password field now displays the Vault, Path, and Key values.

   

9. On the subsequent server side call, Omada Identity retrieves the secret from the vault, encodes and stores it in the vault connection object of the system.

note

If the vault secret is changed in the external vault, then the OPS settings must be committed afterwards.