Skip to main content
System StatusContact Support
VersionOne Community

On-Demand Single Sign-On

On-Demand customers choose the Hosted SSO authentication option for two main reasons: Improved online experience for end users Centralized user access control Hosted SSO uses the SAML (Security Assertion Markup Language) protocol, which is quickly becoming the standard approach for providing federated authentication across applications. For more information about SAML and its benefits, download the SAML Executive Overview. Hosted SSO is included in Ultimate Edition. Please contact your account manager if you would like to implement it.

Configuration Details

The customer must have a SAML Identity provider (IdP) that supports the following SAML 2.0 profiles:

  • IdP-Initiated POST
  • 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 either SAML SSO, Access Tokens, or OAuth2 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. SAML SSO is a difficult protocol to master in code and we have had no luck providing general guidance about how to enable it in code. We have found Access Tokens and OAuth2 to be more suitable for system-to-system communications. Since Access Tokens and OAuth2 work with all user-authentication mechanisms, we have taken to recommending them as the general solution for "robots", with a preference for Access Tokens.

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.