- Identity provider (IdP) via AUP: Federate users and groups from an IdP such as Okta or Microsoft Entra using SCIM. Changes in the IdP propagate automatically to CW IAM. The rest of this page covers AUP in detail.
- Manual user and group management: Create and manage users and groups directly in the Cloud Console on the Users and Groups pages.
- User SSH keys: Users add SSH public keys in their Settings page under Slurm Attributes. SUP uses these keys to enable SSH access to SUNK clusters.
SUNK user provisioning
SUP automatically provisions CW IAM data into your SUNK clusters, regardless of whether that data came from an IdP through AUP or was created manually in the Cloud Console. For setup procedures, see Provision users in SUNK.How SCIM differs from SAML SSO
Because AUP builds on SAML SSO, it helps to understand how the two standards divide responsibilities. SAML SSO lets users sign in securely and supports Just-In-Time (JIT) provisioning, which creates accounts on first sign-in. SCIM requires SAML SSO and goes further by syncing entire directories, including hundreds of users and their group memberships, in real time. Users and groups appear automatically in the Cloud Console without individual invitations or first-time SAML sign-ins. SCIM handles user provisioning and de-provisioning, while SAML handles authentication.Users and groups
AUP synchronizes two core resource types from your IdP to the Cloud Console:- Users: Creates new users, updates profile fields (first name, last name, status), and deactivates users in your IdP.
- Groups: Syncs group memberships and group definitions for better access control. AUP supports only flat groups. Nested groups (groups whose member lists include other groups) aren’t supported and cause provisioning errors.
Key use cases
The following scenarios show how AUP keeps user state consistent between the IdP and the Cloud Console:- Provision users: When you assign a user to the app in the IdP, AUP automatically creates the user in the Cloud Console.
- Update profiles: When you change attributes, first name, last name, or active status in the IdP, those changes overwrite the matching values in the Cloud Console.
- Deactivate users: When you remove a user from a group assigned to the application in the IdP, AUP deactivates the user in the Cloud Console, so only authorized users retain access.
- Sync groups: You can sync group memberships for application-specific group management beyond access control. To sync a group, you must explicitly add it to the push list in the IdP.
- Force sync (Okta-specific): Okta’s force sync feature lets admins manually push updates, which triggers a synchronization of user attributes between Okta and the Cloud Console. This updates user attributes but doesn’t activate or deactivate accounts. For more information, see Okta’s guide.
Set up SCIM
After you configure SAML SSO, set up SCIM to synchronize users and groups from the IdP to the Cloud Console. The exact procedure depends on your IdP, but the overall flow is the same:- Enable SCIM in the Cloud Console: Because SCIM controls organization-wide user data, you must explicitly enable it.
- Enable SCIM in the IdP: In your IdP, open the Provisioning section in the application configuration. This is usually next to the Single Sign-On (SSO) section.
- Configure the SCIM API base URL: This URL is usually prefixed with the organization ID in the Cloud Console.
- Select synchronization options: Choose to push new users, push profile updates, and push groups, depending on the level of synchronization you want.
- Set up authentication: Configure a bearer token for secure communication between the IdP and the Cloud Console.
- Assign users and groups: In the IdP, assign users and groups to the SCIM-enabled application to provision them in the Cloud Console.