Why SSO?
When you start with Ardoq, you will only be able to invite users manually. This requires sending them an email, having them accept the email invite, and signing up. While this is great when you're just getting started, it suffers from a couple of issues:
Scalability: You may have thousands of users. You do not want to manually invite them all. You also do not want to manage their employee lifecycle in multiple places.
Security: Routing all your users to login through your organization's SSO provider means you can enforce policies on passwords and 2FA, you can easily track and monitor logins, and you can revoke users as soon as they leave your organization.
Friction: Digging through an email inbox, opening a link, creating a password all create friction on the login experience for your end users. Friction is an obstacle to democratizing your architecture.
For these reasons, we strongly recommend all customers to setup SSO and then disable plain login by contacting support. If you are worried about being able to have emergency access to your Ardoq organization when plain login is turned off, you can follow our breakglass procedure.
Provisioning
Ardoq supports 3 different kinds of user provisioning (i.e. the process of creating new users in the platform), all of which are compatible with SSO. However, we default to JIT provisioning, discussed below.
Manual invitation
JIT-based (default)
SCIM-based
Manual invitation is covered in this article -- but as mentioned above -- we typically recommend customers to migrate to SSO instead of relying on manual invitation.
Lastly, it's worth clarifying the difference between provisioning and role management:
Provisioning: the creation of new users in the platform
Role maintenance: the management of a user's role, possibly by your SSO provider
For clarity, we include both topics in the following sections as they involve the same SSO integration.
JIT provisioning
When you connect to an SSO provider, you are allowing users who may not currently have a user account to login to Ardoq. A common approach is "just in time" (JIT) provisioning to create a user account on first login automatically, however there are a few different options for handling JIT provisioning:
Control/prevent new user creation
Some customers prefer not to have any JIT provisioning, which means that users can use SSO, but not automatically be created within Ardoq on first login. These users will still need to be invited manually to the platform. These users can still have their role updated by SSO.
Preventing provisioning is typically handled in two ways: by configuring your identity provider (e.g. EntraID) to not allow SSO logins unless the user is "assigned" to the application, or by contacting customer support and having us prevent JIT provisioning on our side. We prefer the former case, as it gives you more control.
Determine which system is the source of truth for role configuration
Because you can configure roles in Ardoq, but also configure roles in your SSO, you may need to resolve which system should be authoritative. For this, we have a setting which allows you to either "only trust Ardoq", "only trust your SSO", or "trust the most recent change". Note that in the last option, there is no precedence -- so if you change a role in Ardoq but then it's different in the SSO, the user's role will change on next login.
The following is a helpful table to understand these interactions.
User management setting | User already exists? | User's role has changed in SSO Provider? | Result |
In-app | No | N/A | User is created with default role |
In-app | Yes | No | User logs in with existing role |
In-app | Yes | Yes | User logs in, keeping their existing role (ignoring the change in the SSO provider, due to the |
In-app and external | No | N/A | User is created with default role. |
In-app and external | Yes | No | User logs in with existing role. |
In-app and external | Yes | Yes | User logs in, and their role is updated to match the SSO configuration. |
External | No | N/A | User is created with default role. |
External | Yes | No | User logs in with existing role. |
External | Yes | Yes | User logs in, and their role is updated to match the SSO configuration. |
Please note that the behavior of "In-app and external" and "External" are identical, but they are both included for completeness. The primary difference is whether you are allowed to make role changes within Ardoq, or whether 100% of your user management will be done externally within your SSO
Both the"user management" and "default role" settings are currently managed through customer support, so you will need to contact us to help get them setup appropriately.
SCIM provisioning
The downside of JIT provisioning is that your current set of users in Ardoq may be stale:
No deprovisioning lifecycle: Users that have left your organization will still be shown as users within Ardoq (although they won't be able to login via SSO).
Stale roles: A users' role will not reflect accurately until their next login, if it has been changed in your SSO.
Missing accounts: Your list of users will be incomplete, as many users may not have logged in yet.
You won't be able to manage users who haven't logged in yet, because they don't exist in the platform.
SCIM solves these issues by doing a regular sychronization between your SSO user pool and Ardoq's user accounts. You can read more about SCIM here.
Please note that SCIM doesn't currently support groups synchronization. This is an item which may be prioritized on our roadmap, but we have good support for user assignment mapping with SSO Attribute Mapping below.
Automatically assigning membership to groups
Ardoq's groups are the best way of managing access control at scale. In order to allow you a flexible way of combining your user attributes in your SSO with Ardoq's groups, we built SSO Attribute Mapping. This allows you to define attributes within your SSO (e.g. Department, Team, etc) and then use these values to assign your users to groups on the Ardoq side.