Recently, I had the opportunity to integrate Salesforce w/ Azure AD SSO, and I wanted to share my experience in performing the configuration as well as any difficulties I had along the way. Overall, the experience was relatively quick and painless, but I did run into a few instances where I was forced to dive a bit deeper and troubleshoot things that otherwise would have been trivial.
For reference, Salesforce offers SP and IdP initiated Single Sign On (SSO). While this guide will mainly focus on Azure SSO w/ Salesforce, I highly recommend configuring further security measures (such as Duo MFA via Azure CA) to improve your organization’s security posture.
This documentation loosely follows the official Azure documents, and includes any workarounds or caveats you may need to know about that the Azure documents don’t cover.
Azure Configuration
1. In Azure, navigate to Home > Azure Active Directory > Enterprise Applications.
2. Select “New Application” on the top left of your screen, and in the search bar type “salesforce”.
3. Select Salesforce from the results panel and then add the app. Wait a few seconds while the app is added to your tenant.
4. Once complete, select the newly created Salesforce application. Navigate to Single sign-on from the left side bar and select it.
5. For the Select a single sign-on method prompt, select SAML.
6. For the Set up single sign-on with SAML page, click the edit/pen icon for Basic SAML Configuration to edit the settings.
7. On the Basic SAML Configuration section, the Azure documentation suggests populating the Identifier, Reply URL, and Sign-on URL fields with values provided by Salesforce Client support team. I found that I could bypass this step and instead populate all 3 fields with my Salesforce Vanity URL.
Currently you can find the value of your organizations vanity URL by navigating to Salesforce, clicking the gear icon in the upper right corner and clicking Setup, then navigating to Settings > Company Settings > My Domain from the left side bar.
8. On the Set up single sign-on with SAML page, in the SAML Signing Certificate section, find Federation Metadata XML and select Download and save the certificate on your computer.
You can optionally copy the Metadata URL instead. To do so, make a note of the App Federation Metadata URL instead of downloading the XML file.
9. On the Set up Salesforce section, copy the Login URL, Azure AD Identifier and Logout URL. These values will be used for the Salesforce configuration.
10. For simplicity’s sake, I’ve left the majority of the attributes as their default values.
In the past, I’ve successfully experimented changing the Unique User Identifier between user.userprincipalname and user.mail. Either value works well and the final choice depends on whether you’d like the users upn or email address to be the identifying value for Salesforce logins.
Salesforce Configuration
- From the Salesforce dashboard, select the gear icon on the top right corner of the page and then select “Setup”.
2. From the left sidebar, scroll down to Settings > Identity > Single Sign-On Settings.
3. On the Single Sign-On Settings page, click the Edit button.
4. At a minimum, select SAML Enabled, and then click Save. I also recommend selecting Make Federation ID case-insensitive but this option is not required to make SSO function.
5. To configure Azure as your SAML IdP, click New from Metadata File.
You may also select New from Metadata URL instead if you’d prefer to use the XML Metadata URL.
6. On the next page, upload the XML File or enter the XML Metadata URL and select Create.
7. On the SAML Single Sign-On Settings page, the fields populate automatically. If you want to use SAML JIT user provisioning:
a. Select the User Provisioning Enabled.
b. Select SAML Identity Type as Assertion contains the Federation ID from the User object.
c. While not required, I do recommend enabling Single Logout Enabled and Use Selected Request Signature Method for Single Logout. Click Save.
I’ve experienced mixed success using Salesforce’s inbuilt JIT provisioning and instead opted to utilize Azure’s Auto User Provision (AUP) feature later on in this tutorial. Currently using custom SRM for single logout appears to be broken but I’ve still chosen to enable it.
8. On the left navigation pane in Salesforce, click Company Settings to expand the related section, and then click My Domain.
9. Scroll down to the Authentication Configuration section, and click the Edit button.
10. In the Authentication Configuration section, Check the Login Page and AzureSSO as Authentication Service of your SAML SSO configuration, and then click Save.
Additional Info- Auto User Provisioning
This section will loosely follow the official AUP documentation.
Azure’s Auto User Provisioning requires a worker account to be created in Salesforce so Azure can make requests through that account via the Salesforce User Account Provisioning API. This worker account will need admin access to Salesforce and have Web API enabled as well.
- From the Salesforce Enterprise Application in Azure, select Provisioning.
2. Select Edit provisioning from the top menu.
3. Set the Provisioning status to On and expand the section titled Admin Credentials.
4. Enter the Salesforce worker account’s username, password and secret token.
Currently the Secret Token can only be reset by appending /_ui/system/security/ResetApiTokenEdit on to the end of your Salesforce domain. (e.g. https://*.my.salesforce.com/_ui/system/security/ResetApiTokenEdit)
5. Populate the Tenant URL field with your Salesforce domain.
6. Click Test Connection and wait for the test to conclude.
7. (Optional) To change the user attribute mappings, expand Mappings and click on Provision Azure Active Directory Users
Here you can edit the range of actions and configure custom attribute value mappings.
The default attribute mapping values are sufficient to enable AUP.
8. Once you’re satisfied with your configuration, click Save.
You can now test the AUP configuration by navigating back to the Enterprise App dashboard, and clicking Provision on demand.
9. Enter the name of a user assigned to the Enterprise Application that you’d like provisioned in Salesforce. Select the user and then select Provision.
The user should now be provisioned in Salesforce and able to log in via SSO.
Issues:
· Accidentally Geo-blocking IPv6 traffic on Azure
· JIT provisioning not working / behaving poorly
· LOTS of AUP issues (invalid licensing, etc.)
