How I Solved It: Enable Users to Easily Log Into Sandboxes Directly from Production

Key business problem

Regularly using sandboxes can be difficult for users and even admins. They need to remember to go to a specific URL and use their sandbox username. Admins need to reset user passwords and update email addresses. In order for them to safely make changes, and for users to test these configuration changes prior to production, we need to make it easy, seamless, and secure for them to log in to the correct sandbox.

Background

Building and testing changes in sandboxes is more than a best practice—it’s a fundamental requirement for building and maintaining high quality business-critical applications. Admins know that having users log in directly to a sandbox for testing can be a daunting task due to a number of hurdles, including:

• “.invalid” is appended to User email in sandbox, so admins must either reset the user password and update the email, or update the user email and the user must complete the email reset process.
• User must go to the correct sandbox URL to log in (test.salesforce.com).
• User must enter the correct username for the specific sandbox.

Admins have to choose between taking time and effort to train users to access the sandbox and following clean development processes, resulting in wasted time and potential frustration for end users.

How I solved it

Step 1. Enable Salesforce identity provider in production

The identity provider is the system that manages identity information and provides authentication services. In our case, we want production to determine if a user has valid credentials, so we need to enable production as the identity provider—which we can easily do with a few clicks!

1. Go to Setup, then Identity Provider, and click Enable Identity Provider.

2. Salesforce automatically creates a certificate when you enable your org as an identity provider. Click Download Certificate to download it.

3. Copy the “Salesforce Identity” SAML Metadata Discovery Endpoint.

Step 2. Set up single sign-on in your sandbox

Now we need to configure the sandbox to allow users to access the sandbox by verifying their identity against the identity provider we created in Step 1. This is referred to as single sign-on (SSO) as it allows the user to log in to multiple systems (in our case, production and sandbox) using a single identity. Follow these steps:

1. Log in to sandbox.

2. Go to Setup, then Single Sign-On Settings, and click Edit.

3. Check the box for SAML Enabled.

4. Click Save.

5. Click New From Metadata URL in SAML Single Sign-On Settings.

6. Paste the SAML Metadata Discovery Endpoint URL you previously copied from production in Step 1. Then, click Create.

Note: This step fills in a few items automatically, like issuer and Entity ID. You need to fill out a few more items below.

7. In the Identity Provider Certificate field, click Choose File and upload the certificate that you downloaded in Step 1.

8. For SAML Identity Type, choose Assertion contains the User ID from the User object.

Note: This step tells the sandbox how to find the matching user. By selecting User ID, we tell the sandbox to match on the Salesforce UserId, which will be provided by the identity provider from production.

9. Uncheck ‘single logout enabled’ if checked (if enabled this would log users out of production when they log out of the sandbox, and would require additional configuration to enable).

10. Click Save.

11. Copy the Entity ID.

12. Copy the Login URL.

Step 3. Create a connected app in production

1. In Setup, go to App Manager and select New Connected App. Configure the new connected app as follows:

• Name: This is what you want it to say in App Launcher. For our demo, it’s named “Test Sandbox SSO”.
• Web app settings: Enable SAML
• Entity Id: Entity ID value from sandbox in Step 2
• ACS URL: Login URL from SAML Single Sign-On Settings in sandbox from Step 2
• Subject Type: User ID
• IdP Certificate: Select the one downloaded in Step 1 that was also used in sandbox.

2. Click Save.

Step 4. Grant access to the connected app for initial testing

Next, you need to grant access to your connected app. For initial testing, you should only grant access to yourself.

1. Click Manage on the connected app.

2. Add to profiles (manage profiles) or permission sets (manage permission sets) that need access to this connected app.

Step 5. Add the connected app to App Launcher

Now, we need to give users a way to launch the connected app. We’ll make the connected app accessible via App Launcher in production.

1. Copy the IdP-Initiated Login URL from the SAML Login Information section on the connected app.

2. Click Edit Policies on the connected app.

3. In Basic Information, paste the IdP-Initiated Login URL into the Start URL field.

4. Click Save.

Note: Do not right-click and copy the link address. In Lightning, this includes JavaScript redirect language. You need to highlight the actual text of the link on the page and press ctrl+c on your keyboard to copy it.

Now, when you click on the app in App Launcher, it launches the start URL, which kicks off the “identity provider initiated” SSO flow to the specified sandbox!

Step 6. Test it out!

Now, let’s test to see that the process works.

1. Go to App Launcher in production.

2. Find the name of your connected app and click on it.

3. You’ll be automatically logged in to your sandbox!

Step 7. Encrypt the assertion for more security

The certificate that was created in Step 1 encrypts the connection between production and sandbox, but the assertion—the information that production sends to the sandbox about the specific user—is currently sent in plain text and is not encrypted. Encrypting the assertion is recommended as it increases your security and helps prevent man-in-the-middle attacks.

This step is easy! Read my blog post for details on how to encrypt the assertion.

Step 8. Grant access to users

1. Create a new permission set, give it a name and a description, and click Save.

2. Click Assigned Connected Apps in the permission set, and select the connected app that you created in Step 3.

3. Click Manage Assignments and assign the permission set to users who need to log in to the sandbox.

Business results

Now, admins can provide users access to a sandbox with a permission set! Users can simply click on the app in App Launcher and they are magically logged in to the sandbox. This helpful shortcut works for admins, too.

Note:

• This approach is configured to match on the User ID, which means it will only work for users who exist in production when the sandbox is refreshed. You can modify this approach to allow you to create a user in a sandbox by matching on the Federation ID instead of the User ID, and adding a flow or manual process to set the Federation ID.
• When you refresh a sandbox, you need to re-enable the SSO settings in the sandbox and update the connected app. This can be done in less than 5 minutes, which is a lot faster than training people on using sandboxes!

Do try this at home

This is a very real example, and while it has a number of steps, there is a huge payoff. Try this yourself and make it easy for you, and your users, to get the most out of the great development tools Salesforce offers.

Let us know what you thought of this solution, and tell us how you want to use it with #AwesomeAdmins #HowISolvedIt on Twitter.

Resources

• Salesforce Help: Configure SAML SSO Between Salesforce Orgs or Experience Cloud Sites
• External Site: Gorav Seth’s Blog: Single Sign On from Production to Sandbox

Want to see more good stuff? Subscribe to our channel!