This feature is available in Catalyst, Enterprise, and Ultimate editions.
SAML-based Single Sign-On is a security configuration option available to on-demand VersionOne customers. Using SAML, VersionOne integrates with your SSO environment and defers to your identity provider for user authentication when anyone attempts to access your VersionOne instance. This eliminates the need for separate credentials managed inside VersionOne. It also gives you better control over authentication, access and more flexibility with password rules for your users.
If your organization is using SAML-based SSO and you’d like to configure your On-Demand VersionOne instance to participate, contact your Account Manager for additional details. On-Demand customers choose the hosted Single Sign-On (SSO) authentication option for two main reasons:
Improved online experience for end users
Centralized user access control
For additional information about SAML, please refer to the SAML SSO Overview page.
The following diagram illustrates SAML SSO using the VersionOne web application
- On-Demand Customers are only responsible for the Identity Provider
- This diagram illustrates an unauthenticated user flow that starts with the user trying to access the VersionOne web application.
- VersionOne depends on an external (3rd party) service provider which is why VersionOne and the service provider are shown as separate entities.
The customer must have a SAML Identity provider (IdP) that supports the following SAML 2.0 profiles:
SP-initiated POST/POST or Redirect/POST
To add the VersionOne Service Provider (SP) to your Identity Provider (IdP), we’ll provide our SAML 2.0 metadata file for import, as well as guidance on relaystate. The metadata file contains URL endpoints and all necessary public keys.
To configure the VersionOne Service Provider (SP) for your instance of V1, we’ll need your Identity Provider (IdP) SAML 2.0 metadata file, including any public keys used for signing or encryption (either in the metadata or separately). We will also need to understand the attribute contract used to map an attribute to the V1 username (e.g. SAML_SUBJECT), and how signing and encryption need to be configured.
In addition to SAML configuration on both sides, the application’s usernames need to be updated to match those passed in the attribute contract, and all integrations need to be updated to use SAML SSO authentication to access the API.
Warning About Integrations
Once SAML SSO is enabled, clients must use Access Tokens for authentication to the API endpoints. In other words, if you have working integrations or other code using the VersionOne API Endpoints, your existing code will break. Access Tokens are more suitable for system-to-system communications. Since Access Tokens work with all user-authentication mechanisms.
If you run into specific problems during migration, you can open a support ticket. Or, if the whole process sounds like more that you want to take on alone, you can engage our technical services for a fee.