Authentication and SSO
Restricting sign-in methods
Organization admins can set sign-in restrictions to control how members are able to authenticate when accessing their Mode Workspace.
- Navigate to the Mode home page.
- Click on your name in the upper left corner.
Workspace Settingsfrom the dropdown menu.
- In the People section, click on
By default, users can log into your Mode Workspace with all of the following methods of access. Toggle off any methods that you do not want to allow users to authenticate with:
- Username and password
- SAML provider of your choice (if configured)
WARNING: Do not disable all sign-in methods. If all methods are disabled it will be impossible for anyone to sign-in to your Workspace, including admins, and you will need to contact our success team for assistance.
Admins may define one more more custom SAML identity providers that your Mode Workspace can use to authenticate users:
- Navigate to the Mode home page, click on your name in the upper left corner of the screen and click
Workspace Settingsfrom the dropdown menu.
- In the People section, click on
- To add a new SAML provider, click
+ Add New Provider. To edit or delete an existing provider, click the
gearnext to it in the list and click
- Enter the SAML configuration and click
Updatewhen you are finished.
Custom providers will automatically create user accounts in Mode for emails that match your organization’s claimed domain. Setup is required for each provider. Once you create a new provider in Mode settings, you will see the following information which may be required for set up in your SAML provider:
- Assertion Consumer Service URL
- Entity ID
- Provider Token
SCIM is a protocol that lets enterprise identity providers (IdPs) integrate with and provision applications. This allows large Workspaces to keep all of their applications up to date with their org chart and maintain centralized control of app and data permissions.
Once you are integrated through SCIM, you will be able to provision users into Mode and manage Mode group memberships through your IdP, rather than needing to do it within the Mode UI. This allows you to manage Mode from the same place and in the same way that you manage other applications, and synchronize identity information like name and email across all of the apps that your members use.
The effect is a less tedious workflow for application administrators, resulting in tighter security and a more effective and accurate deployment of Mode into your org.
The following provisioning features are supported:
Push New Users: New users created through OKTA will also be provisioned in Mode.
Push User Deactivation: Deactivating the user through OKTA will remove the user from the Workspace and all groups in Mode. If they are reactivated they will need to have any groups reassigned to restore associated resource entitlements.
Push Profile Updates: Updates made to the user's profile through OKTA will be pushed to the third party application. First Name and Last Name will be combined as the Full Name in Mode.
Group Push: Groups and their members can be pushed to Mode. You can find more information about using group push operations here: Using Group Push.
Reactivate Users: Reactivating the user through Okta will reactivate the user in Mode. They will need to have any groups reassigned to restore associated resource entitlements.
Import Groups, and
Sync Passwordare not currently supported.
Mode requires that SCIM customers have completed the SAML setup process and have a working Okta-Mode integration before setting up provisioning features with SCIM. If you wish to use SCIM, your Mode Workspace must have SAML configured as the sole signin method.
Attributes and Mappings
Mode supports users pushed from Okta with Okta mastering the
emailType attributes. Mode uses only the user’s
primary email internally. While Mode accepts any
userName, we recommend that this attribute be set to the primary email (the Okta default).
Mode-mastered attributes are only supported in the initial SCIM setup and matching process.
Mode supports designating admin users via specifying admin as the value of the role attribute. Other values for role will be ignored.
Specify admins in Okta to ensure users retain their Mode roles. To see who is currently an Admin, go to Workspace Settings > Members in Mode.
Users and Groups
Mode supports Group Push with Okta, which allows admins to push groups from Okta to Mode, as well as manage groups that were created in Mode through Okta.
Note: Users need to be assigned to the Mode application before they will be included in pushes of Groups that contain them.
For more information on Group Push, see Okta's documentation on Using Group Push and Enhanced Group Push.
What is the user’s experience when using Mode at the time Okta is implemented?
A user’s session on Mode will not be disrupted, unless:
- That user is placed in an Okta group that differs from their Mode group in the process, and the permissions that propagate to them once their account is activated in the Mode Okta app differ from before, they may lose access to resources.
- They are correctly mapped to the appropriate groups/permissions, but their new Okta permissions differ from their former Mode permissions. If their new permissions are different, they may lose access to resources.
What is the user experience when group permissions are changed AFTER the app is active and users are in groups?
This change takes effect in real time and user access to resources are updated instantly.
If a user was accessing a resource at the time of the change and Okta permissions no longer allow this user to have access to said resource, the user’s session will likely fail with a 404 error on the next back end call.
Any new resources available to them would show up in the Mode app interface where they did not exist before, on the next page load for that resource.
Key Takeaway:When Okta Group management is enabled, Mode users' permissions will reflect the access to the Mode resources (collections and datasource connections) assigned to the Okta groups of which they are a member.
What risks exist and how can we mitigate them?
Changes to groups and permissions during implementation have the potential to grant users access to resources that were not previously accessible to those users.
- In order to decrease risk, begin this process with a test by creating and mapping 1-2 users as you would expect to do for the rest of the organization.
- Follow the steps above to assign these 1-2 users to a group within Okta & Mode.
- Confirm these 1-2 users were implemented successfully, and reconcile the results between Mode and Okta to ensure accuracy of expected behavior before implementing the rest of your organization.
How to create the Mode Administrators Group?
What is the unique identifier for the push? Do usernames/names from Okta transfer to Mode?
Mode uses the email in Okta to link to existing Mode accounts. If a user is signed up for Mode as firstname.lastname@example.org but in Okta they are just email@example.com, we won’t link their accounts correctly. From Okta we use the email, given name and family name fields to determine email and name for Mode. And our integration supports updating these values when they are updated in a user’s Okta profile.
After setting up the SCIM integration with Okta + Mode, shouldn’t the push groups feature add existing members to the corresponding Mode group?
- First, unassign and then re-assign your users before pushing the groups.
- To do this: When you enable the Okta SCIM integration, Okta does not let Mode know about any existing users who are assigned to the Mode app in Okta, so those users are excluded from any changes. In order to correctly link them via SCIM, you must un-assign the users and re-assign the users to Mode in Okta. Then the SCIM features will work for those users (pushing to groups, updating name and email, de-provisioning their account).
What impact does the deprovisioning step have in Mode itself? Does it remove that user entirely from Mode?
During this time after un-assigning and before re-assigning, these users will not have access to Mode. This does not affect Mode as this step exists on the Okta side.
Do we have to go back and assign anything specific to the users in Mode once they are all re-provisioned afresh?
No, once the users have been re-assigned, provisioning will now exist in Okta and not in Mode; however, if you have groups in Mode that aren’t in Okta, those members might lose membership to those groups in Mode. This is why it is important to check which users are a part of which groups in both Mode and Okta and mirror them 1:1.
Is there a way to ensure that admins can’t add new users/change user groups once the Okta integration is in place?
Once a user or group is linked via Okta, the options to edit it in Mode are removed.
With the admin role attribute, is there a way to create a separate Okta group for Mode admins, and assign them the role = “admin” attribute?
Yes. You would need to use the “Assign to Group” feature under the assignments tab and a modal will appear with the option to add roles which apply to everyone in the group:
Click ‘Add Another’ and then type ‘admin’ and then click ‘Save and Go Back’.
Why is my group not appearing in Mode? What is the difference between assigning a group and pushing a group?
When using the “Assignments” tab in Okta to assign a group to Mode, each member of the group will be given access to Mode. In order for the group object to be pushed to Mode, you must add the group using the “Push Groups” tab.
NOTE: When pushing a group to Mode, only users who are already assigned to the Mode app will be included. We recommend first using the “Assignments” tab to ensure all members of your group have access to Mode and then using the “Push Groups” tab to push the group to Mode.
How do I remove a group from mode once it's been assigned a push group?
Here are the steps to remove a group from Mode once it's been assigned a push group in Okta:
Push Groups, click
Unlink Pushed Group
- From the
Unlink Pushed Grouppane, select
Delete the group in the target app (recommended)
- Log in to
Modeand observe the group should be deleted
Screenshot of step 2: Screenshot of step 3:
What is the "Everyone" Group?
The "Everyone" group in Mode exists only in Mode and cannot be linked via SCIM. It contains the current active members of an organization in Mode. So when a user is removed/banned from Mode (via SCIM or any other means), they are removed from the "Everyone" group in Mode.
How does Okta SCIM relate to permissions in Mode?
Setting up groups with SCIM and granting those groups certain permissions in Mode ensures consistency and security, since a user’s access is determined by their group memberships.
For example, you have the power of assigning + pushing a group from Okta to Mode, with permissions set on that group in Mode. When the groups in Okta align with permissions in Mode, then the users get access to Mode
and(within Mode) only the data they should have access to.
Can SCIM be enabled on our existing Okta Mode app without negatively impacting access for current, manually provisioned user accounts?
Yes. Turning on SCIM won’t affect existing users in Mode. And manual paths to joining an organization are still available with SCIM turned on (aka invites). However, once a user is linked via SCIM future changes need to be made through the Okta/SCIM API to ensure that your Okta setup is accurately reflected in Mode.
You also have the ability to allow multiple log-in methods within Mode, so if a user doesn’t have access to the new SAML provider, that user can fallback to the log-in method they were using previously.
What happens if Okta breaks? Can admins have a backdoor to still log in to Mode even if our other authentication methods have been turned off?
In this situation, you may reach out to your Mode customer success manager and Mode will enable the SSO option of your choice in order for you to retain access to Mode.
Is there a best practice for when the user managing Okta SCIM leaves my organization?
A best practice here would be to use a service account to set up Okta SCIM instead of having this set up with a real user. This would help you avoid a possibility of the SCIM integration breaking if that user leaves the company.
By default, logged-in sessions to Mode expire after 30 days, at which point users must re-authenticate. If you are an admin and would like to adjust the session expiration length for your Workspace, please contact us.
Was this article helpful?