Domino Blueprints

Azure Entra user-based credential propagation for Domino

Article topics

Security, IAM, RBAC, OAuth, AD/Entra ID

Intended audience

Cloud administrators, IT professionals, Security teams

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, 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

diagram

Technical overview

  1. Each Domino instance establishes an OIDC trust with an AD Application. This allows Domino to request and manage tokens on the user's behalf.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. When the consent/offline token expires, the user is again presented with the authorization url to provide consent.

To learn more, check out the github repo here.