Connect an identity provider
Domino Cloud ships with a pre-built Security Assertion Markup Language (SAML) 2.0 single sign-on (SSO) provider, disabled by default. Enabling it is a joint task: you configure the application on your provider, and Domino Support completes the connection on the cluster.1
Configure the SAML application in your provider
Point the application at
https://{your-cluster-name}.domino.tech/auth/realms/DominoRealm/broker/saml/endpoint, which serves as both the recipient and the destination of the sign-on process. Domino identifies each user by email address and derives the username from it, so send an email attribute whenever the NameID is not an email address. Add firstName and lastName to spare users from entering their details at first sign-in.2
Decide whether the provider also drives roles
To manage Domino roles in your provider, set a multi-valued
domino-system-roles attribute on each user. Domino Cloud accepts Practitioner, CloudAdmin, Librarian, and ProjectManager. Comma-separated values are not supported, so pass each role as its own value.3
Send the connection details to Domino Support
Domino Support needs the single sign-on service URL, the certificate for signature validation, whether roles are integrated, and the label you want on the login button. Domino Cloud does not support provider-initiated sign-in, so users start from the cluster login page either way.
domino-system-roles from provider groups.
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. CloudAdmin is the administrative role on Domino Cloud. Assign roles in the Admin application under Users, or map them from your identity provider. Only a CloudAdmin can grant roles.CloudAdmin cannot manage configuration records or feature flags, and SysAdmin is not available on Domino Cloud, so a change that depends on either goes to Domino Support.
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, assign the Data Analyst role: the same access minus model features, Hardware Tier edits, and Compute Environment management. Enabling it in the first place takes a configuration record and a restart of Domino services, neither of which CloudAdmin can do.
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. What you control is who holds Practitioner at all, who holds ProjectManager, and where ownership lands when someone leaves: CloudAdmin can archive a Project and transfer it to a new owner from the Admin application. See Collaborate on Projects for what each collaborator role can do.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.
- Authentication and SSO: SAML attributes, provider specifics, and role integration.
- 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.