Connect an identity provider
Domino runs Keycloak in a pod on your cluster, and every sign-in goes through it. Set Keycloak up first, then add federation on top.1
Initialize Keycloak
Keycloak is at
https://<your-domino-domain>/auth/. Sign in to the administration console at least once to initialize the service. On a fresh installation, enable user registration there if you want people to sign themselves up.2
Federate to your directory
Connect Lightweight Directory Access Protocol (LDAP) or Active Directory for user lookup and password verification, which also disables local account creation. Or broker Security Assertion Markup Language (SAML) or OpenID Connect (OIDC) single sign-on (SSO) so an external provider performs the authentication challenge and returns a token with the user’s properties.
3
Map roles and organizations from the provider
Add an Attribute Importer mapper named Domino System Roles, with user attribute
domino-system-roles, so role synchronization drives Domino roles from your provider. A second mapper, Domino Groups, with user attribute domino-groups, enrolls each user in a Domino organization named after their provider group. That one also needs the configuration key authentication.oidc.externalOrgsEnabled set to true and a restart of Domino services.4
Limit concurrent sessions
Optional. Cap how many sessions a user holds at once with a Keycloak authentication flow: a browser flow for local or directory authentication, a post-sign in client flow for SSO, and a separate flow to cover API access.
Assign global roles
A global role grants capabilities across the whole deployment, independent of any Project. Every user starts with Practitioner, which covers creating Projects, running Jobs, starting Workspaces, and publishing Apps. Roles are additive, so a user holding several gets the union of their permissions. SysAdmin is the full administrative role, and on a new installation the first user to sign in holds both SysAdmin and Practitioner. Assign roles in the Admin application under Users, or map them from your identity provider. SysAdmins can grant any role to any user.
CloudAdmin appears in the role list as well, but exists only on Domino Cloud.
Work with roles has the full permission matrix for every role, including the ones with no administrative reach. To hand a user a narrower Practitioner, enable and assign the Data Analyst role: the same access minus model features, Hardware Tier edits, and Compute Environment management.
Project creation and ownership
No role grants Project creation on its own. Any Practitioner can create a Project, and whoever creates it becomes the Project owner. Ownership carries the authority that matters at the Project level: only the owner can change a Project’s visibility or its name, and only the owner can transfer ownership or archive it from inside the Project. Inviting a collaborator is the owner’s action or a contributor’s, not an administrative one, and Collaborate on Projects has the full permission table. What you control is who holds Practitioner at all, who holds ProjectManager, where ownership lands when someone leaves, and the boundaries owners work inside. These configuration records set those boundaries:Provision and deactivate users
Configure email services before you create users; user creation depends on them. Add a user from the Admin application by email address and assign roles at the same time. The user receives a notification and an invitation, and must follow the setup link to finish their profile. Deactivating a user deletes all of their Personal Access Tokens for you, but leaves their Workspaces, executions, and Projects behind, so work through the cleanup in order.1
Deactivate the account
Find the user under Users in the Admin application and deactivate them. Deactivation is reversible and you reactivate the same way, but the deleted tokens do not come back; the user creates replacements.
2
Stop and delete their Workspaces
Search Reports > Workspaces for Workspaces the user owns, and delete them.
3
Record what has to keep running
Reports > Executions lists the Domino endpoints and Apps the user owns. Note the ones that must stay available.
4
Transfer or archive their Projects
From Reports > Projects, transfer each Project to its new owner or archive it, then restart whatever you recorded in the previous step.
Credentials for automation
Give shared automation a Domino Service Account rather than a person’s Personal Access Token. A service account’s tokens belong to no individual, so deactivating a departing employee never breaks a pipeline. Only administrators create service accounts, and only through the Domino API. A service account inherits the roles of whoever created it, so check and adjust them before you issue a token: each token carries the roles the account held at the moment of creation, and later role changes do not reach tokens already issued. Tokens expire after four months by default, and you revoke them individually or by deactivating the account. Personal Access Tokens stay with their owners. The Personal Access Tokens panel lists every token in the deployment with its owner, creation date, last use, and status, and you can revoke or delete any of them, in bulk if you need to. You cannot issue a token for another user, and you cannot read a token value: only its creator can retrieve it, only at the moment of creation.Audit who has access
When a record of who approved something matters as much as the change itself, require an e-signature on critical actions.
Related
- Sharing and access: how practitioners grant access to what they own, and how Project and entity permissions stack.
- Work with roles: every role and the exact actions each one permits.
- User authentication: Keycloak setup, directory federation, and single sign-on.
- Synchronize SSO groups and roles: drive Domino organizations from provider groups.
- Manage organizations: group users so Project access follows the team.
- Reset password: restore access for a user locked out of a local account.
- Protecting tokens and API keys: storage and rotation practices for credentials.