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.