Managing Remote Users#
When using OIDC or SAML as your authentication protocol you can configure Determined to remote provision and manage your users.
Remote user provisioning lets you include and synchronize any information about the user stored in your IdP such as their username, display name, and groups. Once configured, you can manage remote users without having to manually modify the users or update them via SCIM. Each time the remote user accesses Determined, their information is synchronized.
Attention
This feature applies only to Determined Enterprise Edition.
Enable Remote User Management#
Set the Auto Provision Option#
The first step is to configure the master configuration file to enable user auto-provisioning and the remote management of any information attached to the users.
Enable OIDC.
Set
oidc.auto_provision_users
option totrue
in your master configuration file.
Note
If scim_enabled
is true
, then oidc.auto_provision_users
must be false
.
For example:
oidc:
enabled: true
provider: "Okta"
idp_recipient_url: "https://determined.example.com/oidc/sso"
idp_sso_url: "https://dev-00000000.okta.com"
client_id: "xx0xx0"
client_secret: "xx0xx0"
auto_provision_users: true
always_redirect: true
posix_user_claim: "preferred_username"
display_name_attribute_name: "XYZ"
agent_uid_attribute_name: "user_id_key"
agent_gid_attribute_name: "group_id_key"
agent_user_name_attribute_name: "agent_user_key"
agent_group_name_attribute_name: "agent_group_key"
Enable SAML.
Set
saml.auto_provision_users
option totrue
in your master configuration file.
Note
If scim_enabled
is true
, then saml.auto_provision_users
must be false
.
For example:
saml:
enabled: true
provider: "Okta"
idp_recipient_url: "https://determined.example.com/saml/sso"
idp_sso_url: "https://myorg.okta.com/app/...sso/saml"
idp_metadata_path: "https://myorg.okta.com/app/.../sso/saml/metadata"
auto_provision_users: true
always_redirect: true
posix_user_attribute: "uid"
agent_uid_attribute_name: "user_id_key"
agent_gid_attribute_name: "group_id_key"
agent_user_name_attribute_name: "agent_user_key"
agent_group_name_attribute_name: "agent_group_key"
Determined sets the username of the user to the IdP email address. You cannot set the username independently.
To automatically link custom claims, you can configure the attribute name with the relevant field. For example:
agent_uid_attribute_name: "custom_uid_attribute_name"
Note
Once this feature is enabled and an agent UID/GID is assigned to a user, it can only be reset
manually. To revert the UID or GID back to the default value specified by
security.default_task.uid(gid)
, an admin must manually remove the agent UID/GID settings for
that user.
Set the Groups Claim Name Option#
Determined receives OIDC and SAML claims via a JSON Web Token (JWT) that you send from your IdP. If there is a group that does not already exist in Determined, then the system creates the group.
To enable group membership synchronization:
Set the
groups_attribute_name
option to match the claim name for group memberships from your authenticator (i.e., either a custom user attribute such asgroups_memberships
orusergroup_memberships
, or the authenticator’s groups claim, passed in asgroups
, etc.).
For example, in the following claim, let’s say the user-group information is passed through
group_memberships
in your IdP.
{
email: dee.ray@example.com
group_memberships: ['A', 'B'],
displayName: "Dee Ray"
}
Then, Determined creates the following user:
{
username: dee.ray@example.com
groups: ['A', 'B'],
displayName: "Dee Ray"
}
Set the
groups_attribute_name
option to match the claim name for group memberships from your authenticator (i.e.,groups_memberships
,usergroup_memberships
, etc.).
Each time the authenticated user accesses Determined, their information is passed to Determined, and group memberships are updated. For example, when a user is assigned to a new group via your IdP, that information is updated in Determined.
Complete the Auto Provision Process#
Once auto provisioning is configured, the user simply signs in with their username.
For example, to sign in to Determined via Okta, the user performs the following steps:
Visit the Determined URL, e.g.,
https://determined.example.com
.Under Sign in with Okta, enter the SSO-enabled email address.
If the sign in is successful, Determined provisions the user, adds the user to the user table, and authenticates the user to Determined.
Manage Remote Users and Groups via the WebUI#
To manage users and groups in the WebUI:
Sign in to the Determined cluster via the Determined URL, e.g.,
https://determined.example.com
, as a cluster admin.View Admin Settings by selecting your profile in the upper left corner and then choosing Admin.
Actions you can take include adding new users, switching existing users to remote users, performing bulk actions, and more. For example, using the filters, you can select to view only active users. You can also manage user groups.
To find out how to manage remote users via the WebUI, including adding a new remote user, visit managing RBAC via the WebUI.
Handling SSO Session Expiry#
SSO users are redirected to the SSO provider’s authentication URIs when their session token has expired, rather than displaying the Determined sign-in page. This ensures a continuous user experience without manual intervention when sessions expire.
Note
The always_redirect
option enables this behavior. If a user does not have a session token,
this option generally bypasses the Determined sign-in page, except when the user signs out
through the WebUI. If multiple SSO providers have always_redirect
enabled, the system will
attempt to use each provider. This differs from the session expiry handling described above.