Manage Users and Teams with SCIM and Okta

Configuring SCIM for your Sigma organization will allow you to centralize management of users and teams through Okta. This guide provides the steps required to configure Okta Provisioning for Sigma Computing.

Requirements

• You must be an organization Admin in Sigma to initiate provisioning.
• Your Sigma organization should already be authenticated with Okta using SAML; see Manage authentication

Understanding

What is SCIM?

The “System for Cross-domain Identity Management”, better known by its acronym SCIM, is a standard for the automation of user and group provisioning between two services.

In this case, the two services are Okta and Sigma.

SCIM with Sigma and Okta

Configuring SCIM for your organization allows you to create and manage users and groups in Okta and automatically push them to your Sigma organization as users and teams.

Once SCIM provisioning is enabled for both services, all management of users and teams must be done in Okta. These are visible in Sigma, but not editable.

🚧

You shouldn’t use SCIM provisioning for the same user across multiple IdPs.

SCIM with SAML

Before you can configure SCIM for your organization, you will need to enable SAML authentication in Okta and Sigma.

SAML allows Single Sign On (SSO) and management of users. However, syncing new users and updates between Okta and Sigma requires the user to log in to Sigma. When you add SCIM to your SAML configuration, you will gain the ability to manage Sigma teams from Okta, and both user and group/team data in Okta will automatically be pushed to your Sigma organization, regardless of user login.

Features

The following provisioning features are supported:

Push New Users

• Okta automatically adds new users you create and assign to your application as members in Sigma. If a Sigma account type isn't specified in Okta, the default Lite account type is assigned.

Push User Profile Updates

• Okta automatically pushes updates made to the user's name (‘given name’ and ‘family name’) in their Okta profile to Sigma.
• Updates made to a user’s ‘user type’ (via that application Assignment page) are automatically pushed to Sigma.

Deactivate Users

• Deactivating a user through Okta will deactivate the user in Sigma.
• Note: The user's profile information will be maintained as an inactive user.
• Note: Sigma transfers ownership of any documents created by the user to the Admin performing the deactivation. Any documents located in the user’s My Documents folder are automatically transferred to a folder in the administrative user's My Documents.

Reactivate Users

• Sigma user accounts can be reactivated by reactivating the corresponding account in Okta.
• Reactivated users will automatically regain their Sigma team memberships, if they were added to Sigma via an Okta group.

Push Groups / Teams

• Groups created in Okta will be created as teams in Sigma.

Push Group / Team Updates

• Okta pushes updates made to a group (group name and members) for users assigned to the configured application to the corresponding team in Sigma.

Deactivate Groups / Teams

• Deactivating a group in Okta deactivates the corresponding team in Sigma.
• Note: Any documents located in the team’s workspace folder are automatically transferred to the My Documents folder of the Admin account type user performing the deletion.

Transition to SCIM

Are you considering transitioning to SCIM after already creating users and teams in Sigma? Have you already created users with SAML authentication but are new to SCIM provisioning?  This section discusses what to expect when you transition to SCIM.

Can I edit users and teams in Sigma?

All management of users and teams must be done through your IdP. While not directly editable in Sigma, both are displayed in your Sigma Admin Portal.

What happens to my existing users?

This depends on where your users were created: in Sigma’s Admin Portal vs in Okta with SAML. Both scenarios are listed below.

If you have existing users in Sigma’s Admin Portal:

Existing users will remain in Sigma. However, they will no longer be editable through the Sigma Admin Portal.

Users: Okta allows you to link to an existing user with the same email address in Sigma. No work will be lost, and Admin management of that user can then be maintained through your IdP. Alternatively, you may be able to import users from Sigma into your IdP.

User Account Types: If you switch management of a user originally created in Sigma over to your IdP, Sigma will automatically respect the account type defined in the IdP, regardless of what was originally set in Sigma.

If your have existing users in Okta with SAML:

Okta requires that any users already assigned to the app be removed and re-added when provisioning is switched on for an existing application. This process will not result in the loss of any user work in Sigma.

We recommend the following process for handling this situation:

1. Select an off-hours time slot in which you can conduct the switch.
   During this time, your users will be temporarily removed from the application and subsequently will not be able to log into Sigma.
2. Create Okta groups for your users prior to removing them from your application.
   This is not required; users can be added individually. However, bundling users into groups is recommended for two reasons:
   (1)  If you have a large user base, re-assigning your temporarily removed users in groups will reduce the period of time that your users are locked out of their Sigma accounts.
   (2)  These user groups can be repurposed when you push Okta groups to Sigma to create teams.
3. Un-assign all users from your Sigma application in Okta.
   This can be done from the Assignments tab. Be sure to un-assign individuals and groups.
4. Turn on provisioning.
5. Re-assign all users to your application.
6. Push groups to create teams.

What will happen to my teams previously created in Sigma?

Existing teams will remain in Sigma, but you can't edit them in Sigma.

Okta allows you to link a group in your application to an existing team in Sigma. No work will be lost, and Admin management of that group/team can then be maintained through Okta. When the link is created, the team's membership will automatically be updated to reflect membership of the linked Okta group.

Configuration Instructions

[Prerequisite] Set Up Authentication

If you have not already, connect your Okta instance to Sigma using SAML for authentication; see Single Sign-On with SAML.

Enable SCIM Provisioning

In Sigma:

1. Log in to Sigma as an organization Admin.
2. Navigate to your Sigma Admin Portal.
3. In the left panel, click Authentication to open your organization’s Authentication page.
   Note: If you have not yet configured SAML, please do so now using the "SAML or password" authentication method; see Single Sign-On with SAML.
4. If your authentication method is set to Password, please change it to SAML only.
5. Click the Setup button under Role and Team Provisioning to open the Provisioning modal.
   Note: This section is visible if your authentication method is SAML or OAuth.
6. Review the notes provided on the getting started section of the Provisioning modal. Check the confirmation box, and click Next to continue.
7. You will now be asked to create a token to authenticate your integration with Okta. Enter a token name. Then click Next.
8. Sigma provides you with a Bearer Token. Copy and store it in a secure location. It will be needed to complete your integration.
   Note: If you are configuring provisioning in an Okta Sigma app created prior to February 3, 2021, you will also need the Directory Base URL.
   
9. Click Done.
   Next Steps: Enable SCIM provisioning in Okta.

In Okta:

Open your Sigma application in Okta and configure provisioning for your integration.

Add Users to your application

Open your Sigma application Okta Admin console and assign users to your application integration. You can add users individually or in groups. You changes in Okta are to Sigma automatically. The process adds users and assigns roles; it does not trigger team creation.

If a user has a custom account type, or an user type in Okta that doesn't directly map to Sigma, see Use Custom Account Types with your IdP.

🚧

The user type attribute is case-sensitive. When configuring default account types (Admin, Lite, Essential, Pro), the value indicated should be lower case (e.g. "essential"). Other account type configurations are also case-sensitive, and the value set in your IdP must match the value in Sigma exactly, or errors may occur when trying to provision users

Errors

If you encounter the error below, remove all existing user types in Okta. Then add the user types in Okta again, mirroring the account types found in Sigma.  

Error while trying to push profile update for {email address}: Bad Request. Errors reported by remote server: Request is malformed: Error: Expecting string at 0.1.userType but instead got: null.

Follow the instructions below to add users to Sigma in bulk. The process adds users and assigns roles; it does not trigger team creation.

Provisioning users and groups may take a few moments. To check on provisioning status from Okta, open your Provisioning activity log under Reports. You can also check the People page in your Sigma Admin Portal to confirm that your new user(s) have been added and assigned the appropriate account type. 

Push groups to create teams

Groups in Okta equate to teams in Sigma. Once you configure provisioning in Okta, you can't create new teams directly in the Sigma Admin Portal - you must create all teams as groups in Okta and push them to Sigma.

Teams created in Sigma prior to setting up provisioning remain accessible (but not editable) from your Sigma Administration Portal. You may choose to transition management of these teams to Okta by selecting the Link Group push option. See Enable Group Push for more information.

Troubleshooting Tips & FAQ

Please reach out to Sigma Support with any questions during your configuration process.

(1) I added a new user to my Sigma application, but their account has not shown up in Sigma. What should I do?

• Was the user’s account added to Okta before you set up provisioning? If so, you will need to un-assign and re-assign the user to the application.
• In Okta, check for an error next to the user in the people’s list under the Assignments tab in your Sigma application.  
• Does the user have a first name and last name listed in their Okta Profile?

(2) My Sigma organization has existing users and teams that were previously created through the Sigma Admin Portal. Will these be affected when I set up provisioning with Okta?

• No. Existing users and teams will remain in Sigma; however, they will no longer be editable through the Sigma Admin Portal.
• A user in Okta can be linked to an existing user with the same email address in Sigma. No work will be lost, and Admin management of that user is now maintained through Okta.
• You may choose to link a group in Okta to an existing team in Sigma. No work will be lost, and Admin management of that group/team is now maintained through Okta.

(3) My Sigma organization has existing users and teams that were previously created through the Sigma Admin Portal but are not part of my Okta organization. What options do I have?

• Option 1: Define the corresponding users and groups in Okta before turning on provisioning, so that Okta can link them together.
• Option 2: You can use Okta’s import feature. In the Import tab, click on Import Now. This scans for existing users and groups that aren't defined in Okta, but are present in Sigma. When Okta is done scanning, it presents a list of users that it found in Sigma but not in Okta. For each user that it found, you can decide to create a new user in Okta, to link to an existing user in Okta or to ignore the user. It is suggested that you ignore the scheduler user that Sigma creates as part of your Sigma organization ([email protected]). Refer to Okta’s documentation about Import users for more information. If you choose this option, check Known Issues.

(4) I assigned users to my Sigma application in Okta prior to turning on provisioning. Their accounts are not appearing in Sigma. What should I do?

• Try un-assigning and reassigning these users to your Okta Sigma application.

(5) The Admin who originally set up our provisioning has left or taken on a new role (account deactivated, unassigned, or user type changed). Now we’re hitting errors when attempting to push data from Okta to Sigma. What happened?

• Provisioning is associated with the Sigma Admin who originally set up provisioning in Sigma. If you wish to remove or update this user’s account type, you will also need to remove and re-enable provisioning in Sigma with a new Admin user. This will generate a new bearer token. Provide Okta with the updated bearer token (see enabling provisioning in Okta) and rerun any provisioning tasks that might have failed.

(6) Can I change a user’s user name?

• This action is not recommended. Changing a user’s username will result in the creation of a new account in Sigma. It will not update the existing user’s username.

Limitations

• Importing groups from Sigma teams is currently unsupported. The group gets created in Okta but has no members. As a workaround, after the group is created as part of the import process which imports both users and groups, delete the group in Okta and then recreate the group with the appropriate members. Then, push the group into Sigma by creating a link with the corresponding team in Sigma.
• Importing users using the “link to an existing user in Okta” option is currently unsupported. As a workaround, please assign the Sigma app to the user you wish to link.