Skip to main content
Adaptive Insights
Knowledge and Support - Adaptive Insights

Is it possible to use the same Identity provider to log in to My production and sandbox instance using SAML SSO?

This article includes suggestions and workarounds. Content may not be accurate for all use cases or represent best practices for the latest release. 

We just got our new sandbox instance and I wish to use our existing IDP to connect to both of our instances. How is this possible?

Answer

 

Basically from Adaptive perspective, each instance that a customer has which does not participate in a multi instance should have it's own SAML setup. So each instance will have it's unique SAML URL that a customer will have to configure on their Identity Provider's (IDP) side. This URL is used by their Identity provider to redirect to a given instance, hence the uniqueness of the URL.

 

Assuming that these will be separate instances, these will have unique URLs as well as unique user identifiers. There is really only one way of doing this if Production and Sandbox instances are independent of each other:

 

 

 - On the side of the Identity provider (if it allows for it) to have 2 separate apps to use for Production and Sandbox instances. This means that a user will log into the Identity provider interface (Okta, Azure, Centrify, etc.) and will be presented with 2 links/tiles/gallery applications, one for Production (and it is clearly labeled as such) and one for the Sandbox. They will click on either one and assuming that the set up has been performed correctly, will be redirected to an appropriate instance. This can be done 2 of the following ways:

 

1. Production will use the correct username (99% cases is their actual email address) and authenticate via that to log them into production. Sandbox instance, on the other hand, will have to use Federation IDs that are associated with these users. This ensures that 2 sets of users (for production and Sandbox are unique). The IDP will need to use the proper username mapping to Federation ID, which is not something that we would advise on, but after that is done, the Sandbox app itself should use federation ID to authenticate.

 

2. If the Identity Provider is smart enough to perform a transform, then for a given app (say the Sandbox Adaptive App) it will take a given user from the IDP database of users, drop their domain name and transform it to their sandbox domain. Say we have a user in the sandbox called **John@adaptive.sandbox .com** which corresponds to a user in the IDP data base called **john@adaptive.com**. Then, the sandbox app in the IDP can take the **john@adaptive.com** and *transforms* it to **John@adaptive.sandbox .com** and logs them into the Sandbox. Keep in mind that this is localized to Just the sandbox app, meaning the production app will still authenticate via **john@adaptive.com** to **john@adaptive.com** in the Production instance.

 

If the production and sandbox are a part of a multi-instance model, then you can setup the SAML configuration on both instances. It is fine within the Adaptive Planning application to have the same IDP setup for both instances. If you do so then users who directly want to go to the child instance should be configured with the default company code for the child (from Edit User) and their federation id setup for that instance. Users who want to go directly to the parent instance can be configured with their federation id in the parent instance. Note that on your side you will have TWO urls to login to Adaptive, one for the parent instance and one for the child instance.

  • Was this article helpful?