Welcome! Today we’re going through the process of setting up Single Sign-On through Office 365 for your Salesforce organisation.

NOTE: You will need to have ‘My Domain’ enabled.

Let’s not waste time and get straight into it.

Firstly, for this process we will be using the ‘Federation ID’ field on the User record. Why are we using the Federation Id and not the users Login Name?  Great question, glad you asked …. Salesforce enforces a unique username across all instances and if you use multiple instances (like we do) then the login name usually ends up looking like my.username@my.domain.instance.identifier this obviously differs from your email address!

Setting up the Federation ID

In Salesforce go to setup, then in the quick search box type ‘Process Builder’ and click on it.

Create a New process and name it ‘Federation ID = Email’

In the ‘object’ rectangle, click on it and then select ‘User’ from the dropdown menu. Click the bubble to start the process when a record is updated or created. Also, make sure the ‘Recursion’ tickbox is NOT ticked.

In the ‘criteria’ diamond select the options as they are in the following screenshot.

In the ‘Immediate Actions’ follow this setup:

NOTE: The boxes with the red square are [User].FederationIdentifier

And that’s it! Make sure to Activate your process using the button in the top right of the screen.

At this point it’s a good idea to update the user record you’re going to be testing with so the federation id is mapped!

Also …. Trap for young players!  SSO is case sensitive!  If you’re expecting MyName@MyDomain to map to a Federation Id of myname@mydomain forget it – it wont work.  Make sure your existing email values match the email address on your Azure AD record, otherwise there’s a lot of wasted time ahead!

Now onto setting up Single Sign-On!

Open up and login to your Office 365 go to Admin Centres then Azure Active Directory and click on Enterprise Applications.

From the Azure Active Directory Admin Centre. Click ‘New Application’.  In the search box type ‘Salesforce’ and select it from the results.

While on the integration page click ‘Single Sign-On’. Now select Single Sign-On Mode as ‘SAML-based Single Sign-On’


Now in the ‘Sign on URL’ field enter your instances URL. Eg. https://www.coroma.my.salesforce.com


Enter the same URL into the ‘Identifier’ text box.

In the certificate section click the ‘Show advanced certificate signing settings’

Signing Option – Select ‘Sign SAML response and assertion’

Signing Algorithm – Select SHA-256

Click Create New certificate. We will use this when setting up in Salesforce.

In a new window log in to your Salesforce organisation then go to setup and type ‘Single’ in the quick search box, then click the ‘Single Sign-On Settings’ option. Once in the options, tick the ‘SAML Enabled’ tick box checked

Now click the ‘New’ button next to ‘SAML Single sign-on settings’

For the name you can enter whatever you wish. This will appear on the button that your users will click to login.

The issuer field needs to be populated with the following: ttps://sts.windows.net/60a09ca6-e30b-4f75-a2e1-ffe0ec363c11/. Everyone will have the same issuer.

Using the certificate we previously downloaded from Azure, upload it into The Identity Provider Certificate field.

Populate the ‘Entity ID’ field your salesforce instance URL: https://www.coroma.my.salesforce.com

The Request Signing Certificate dropdown will have populated with the certificate that we’ve just uploaded so select that.

Select the ‘RSA-SHA256’ Request Signature Method.

Select the Assertion Decryption Certificate as ‘Assertion not encrypted’

Select the middle bubble for the SAML Identity Type.

Select the top bubble for the SAML Identity Location.

Again, select the top bubble for the Service Provider Initiated Request Binding.

Identity Provider Login URL: https://login.microsoftonline.com/60a09ca6-e30b-4f75-a2e1-ffe0ec363c11/saml2

Save the record.


Go back to setup and search ‘My Domain’.

Scroll down to Authentication Configuration and click Edit

For the Authentication Service tick both the Login Page and <your button> boxes.

Lets go ahead and test this!

Within Salesforce, go back into the Single Sign-On settings.

Create a test user in both Salesforce and Azure, using the same email address. Log into that email account on Azure and then go to login to your Salesforce using your new button (appears under where you normally enter your details). If all goes well, then you should successfully login as the test user on Salesforce.

If not, Click the ‘SAML Assertion Validator’ button and then paste the SAML response into the box and click the ‘Validate’ button. This will generate what is being processed but this won’t be readable. If you wish to read what is actually being sent take the SAML response to https://www.samltool.com/decode.php and this will decipher the actual processes.

Make sure to check the following if getting an error:

  • Make sure the initial process to populate the Federation ID is working correctly.
  • Ensure you’ve correctly entered the URL’s within Azure and Salesforce (there are quite a few!)
  • Make sure that SAML is enabled on Salesforce
  • Check if the certificate is matching in both Azure and Salesforce
  • Review the SAML Single Sign-On Setting

Stay tuned! There will be a follow up post to make this process even easier for your Salesforce organisation!

Okay so now you have single sign on and everyone is happy!  Next post Just In Time provisioning

Leave a Reply

Your email address will not be published. Required fields are marked *