What is Azure Entra ID and why is it relevant to Domino?

Azure Entra ID (formerly Azure AD) enables secure OAuth-based access control and auditing for cloud resources. In Domino, Entra ID integration allows user-level authentication and audit trails for workloads.

What is credential propagation in this context?

Credential propagation refers to passing Azure AD user access tokens into Domino workloads (Apps, Jobs, Workspaces) so they can authenticate to downstream resources using the user's identity.

What are the security benefits of this pattern?

This method enforces short-lived, user-scoped tokens, avoids long-lived credentials, and supports unified RBAC and auditing within and outside Domino environments.

How is consent handled in the authentication flow?

When a user first accesses an Azure-secured resource in Domino, they are redirected to authorize access. A refresh token is issued and maintained by Domino, allowing continued access without further prompts.

What happens when the consent or refresh token expires?

Users are again prompted with the Azure authorization URL to re-consent. Token revocation or expiration is controlled by Azure Entra ID policies.

Azure Entra user-based credential propagation for Domino

Overview and goals

Entra ID, formerly known as Azure Active Directory (AD) authentication, is an industry standard method using the OAuth standard to secure access to sensitive data. AD also allows for user-level audits for data access, providing a complete audit trail for sensitive data as well as centrally-managed role-based access control (RBAC).

You may already be using Azure AD within your Domino instance for single sign-on, syncing group memberships, or assigning roles via either OpenID Connect (OIDC) or SAML. This pattern expands that integration to include OAuth authorization in addition to authentication.

Propagating a User's AD Tokens to Domino workloads (Apps, Jobs, and Workspaces) allows for a unified RBAC scheme that applies to the user both inside and outside of Domino. Access to resources can be centrally-managed in the tenant, and that access flows down to user executions running within Domino.

On the Azure end, this also allows for fine-grained data and resource access audits outside of the Domino cluster. Azure will log each request with the user's individual identity when they use their personal tokens.

While this document is meant to guide you on configuring Azure credential propagation to Domino workloads based on well-defined policies consistent with your Enterprise Security guidelines, if you have questions or want to learn more, feel free to email Professional-Services@dominodatalab.com. Alternatively, please speak with your Domino Professional Services contact for additional information and support.

Usage scenario

Your enterprise security policy forbids the use of long-lived credentials (username/password, access key, SAS/database token)
You require strong auditing of all data reads and writes
You would like to use OAuth standards to propagate short-lived credentials to Domino workloads
Your data source access is centrally managed via AD, and you want to propagate the same access to Domino

Overview diagram:

Technical overview

Each Domino instance establishes an OIDC trust with an AD Application. This allows Domino to request and manage tokens on the user's behalf.
AD administrators will set API permissions on the AD Application to allow access to your target APIs. This could include Azure Databricks, Blob Storage, ADLS Gen 2, etc.
When a user first requests a token within a workspace, they are presented with a URL to authenticate. This redirects them to the Azure Application, where they must provide consent for the specific APIs they are accessing.
Once user consent is provided, AD passes Domino an access token and an offline refresh token. The user requests the access token in their workspace, allowing them to authenticate to Azure services. The refresh token is hidden from the user, and Domino refreshes the access token regularly on the user's behalf.
The user consent lasts as long as the refresh token does. From the AD tenant you can revoke tokens or use AD features like conditional access to control session times. While consent is active, the access token is available for all of the user’s Domino workspaces, jobs, and scheduled jobs without requiring additional user intervention.
When the consent/offline token expires, the user is again presented with the authorization url to provide consent.

Azure Entra user-based credential propagation for Domino

Author

Article topics

Intended audience

Source code repository

Overview and goals

Usage scenario

Technical overview

Check out the GitHub repo

Vaibhav Dhawan