Skip to main content
An App runs as its publisher. Every viewer sees what the publisher can see, and everything the App does, it does as the publisher. Identity propagation passes the viewer’s identity into your code. Use it when the App must record who did something, prove it, or act with that person’s own permissions. In the Synthetic Transaction Review App from Develop and test, an Approve or Flag decision is anonymous. The App knows a button was pressed, not who pressed it. Compliance needs the reviewer’s name on each decision. An auditor needs proof that the name is real. A bank with regional teams needs each reviewer to see only their own region. Those are the three levels.

Choose a level

Each level includes the one before it. Use extended identity. It supports the widest range of Apps, because the App can identify each viewer and also read data, submit Jobs, and call Domino APIs with that viewer’s permissions. Basic and enhanced identity tell the App who the viewer is but don’t change what the App can reach. Extended identity isn’t required if the App only needs its owner’s identity to run. Such an App runs as its publisher, for example a dashboard that shows every viewer the same data.
Identity headers reach your code only in frameworks that support proxied HTTP headers. Flask and Dash support them by default. Shiny requires Shiny Server Pro.

Basic identity

Domino identifies the viewer on every request, with no setup. With SecureIdentityPropagationToAppsEnabled on, the default, each request carries a token in the Authorization header whose preferred_username claim names the viewer, plus a domino-username header copied from it. Read the token when one is present. Apps with extended identity don’t receive the domino-username header, and a client could supply its own, so read the header only when no token arrived. Dash runs on Flask, so a callback can read the request from Flask’s request context. This version of the transaction review App’s record_decision callback adds the reviewer’s name to each decision:
Commit. The preview shows your username on the next decision. This reads the claim without checking the token’s signature, which is enough to know who is viewing. Enhanced identity verifies it.

Enhanced identity

With enhanced identity, Domino passes a signed JWT in the Authorization header. Your code verifies the signature against Domino’s keys, then reads the viewer’s username, email, and user ID from it. The token’s audience limits it to a small set of Domino endpoints. Use it when a username in a header isn’t proof enough, for example when the decision log feeds an audit.
1

Extract the token

2

Verify and decode the token

Fetch the signing keys from the JSON Web Key Set (JWKS) endpoint, then verify and decode:
3

Read the viewer claims

A decoded payload looks like this:

Extended identity

With extended identity, the App receives a full-scope token for each viewer who consents. It can then read their data, submit Jobs, manage Projects, and do anything else the viewer can do in Domino. In the transaction review App, this is how each reviewer sees only the transactions their permissions allow, and how a Rescore button could start a Job as the reviewer rather than as the publisher.
The App receives the viewer’s token alongside the publisher’s, and your code chooses which one to use for each action. Each viewer consents before the App can act for them. Extended identity stays on for the life of the App once you turn it on.

Before you begin

  • The SecureIdentityPropagationToAppsEnabled feature flag is true.
  • The com.cerebro.domino.apps.extendedIdentityPropagationToAppsEnabled configuration record is enabled. It’s enabled by default.
  • You’re a SysAdmin or CloudAdmin. Each App opts in individually, and only a SysAdmin or CloudAdmin can publish an App that has opted in.
1

Opt the App in

Turn on Allow App to act for viewers in Domino in the App’s Access and sharing settings. This setting is version-defining: turning it on creates a version, and it takes effect after the App restarts. An administrator can also turn it on in the App Preview Settings panel to test it before publishing.
2

Read the viewer's token

Without extended identity, the same code returns the limited-scope token from enhanced identity.
3

Call Domino APIs as the viewer

This Flask route returns the Projects the viewer can access, which can differ from the publisher’s. Domino sets the API address in DOMINO_USER_HOST for every App.
Call get_viewer_token() to act as the viewer and get_publisher_token() to act as the publisher. The same pattern works for any Domino API call the viewer is allowed to make.
4

Publish, deploy, and collect consent

Publish and deploy the App. The first time a viewer opens it, Domino asks for consent. After consent, the App can retrieve the full-scope token. Consent lasts 8 hours by default. Viewers can extend it to 30 days on the consent page. Consent is audited.

Scope mounted data to each viewer

Apps mount the NetApp Volumes and Datasets the publisher can access, so every viewer can read them. To apply each viewer’s own permissions instead, read the data through the dominodatalab-data SDK rather than the mounted path, and pass the raw bearer token from the Authorization header to the SDK client. The Domino API then checks the viewer’s permissions. The domino-username header and the decoded claims identify the viewer but don’t authenticate an SDK call.
  1. Read the Authorization request header and remove its Bearer prefix.
  2. Pass the raw token to DatasetClient.
  3. Read, write, or download Dataset files with the client. The Dataset proxy example has the Python code.
In the transaction review App, the Dataset read moves out of module scope, where no viewer request exists, into a callback that runs per request and reads through DatasetClient with that request’s token. Catch the permission error for a reviewer without access to the AML Dataset and show an empty queue instead of the publisher’s data.

Headers and environment variables

Domino adds these headers to each request it forwards to your App: Domino also sets these environment variables when an App starts: Project-level variables and the user-level variables of the user who starts the App are also available. Use them for secrets and configuration instead of hardcoding values.
  • Operate: Choose who can open the App.
  • Configuration: The feature flag and configuration record behind each level.
  • Extensions: Apps with extended identity that Domino embeds in its own UI.
Last modified on October 27, 2026