Step-by-Step Guide to Build Your Own Salesforce Single-Sign On ( SSO ) Test Lab

SSO is a great option specially from user experience point of view. Once the user logs on to a main application, he/she can then logon to all other applications seamlessly without having to type the username and password separately. Or the user just needs to remember one username and password and that will allow him/her to logon to all other different applications. It’s like having a magic key that automatically opens up all the other doors once you enter through one door.

Salesforce provides different options to configure Single Sign On. This includes

  1. Federated Authentication using SAML
  2. Delegated Authentication
  3. OpenID Connect

For the purpose of this blog post, we will limit our discussion to Federated Authentication using SAML. In Federated Authentication, to keep things simple, there are two main concepts in SSO that you need to be aware of.

  1. The concept of IdP/SP
  2. The concept of IdP initiated login and SP initiated login.

Let’s try to have a basic understanding of these two concepts

  1. IdP/SP: IdP stands for Identity Provider and SP stands for Service Provider. When logging on, IdP is the system that authenticates user by validating his username and password and then subsequently all other applications trust IdP and allow user to access the application if the IdP asserts that the user is a valid user. In such cases, IdP is the system that stores user’s login name and password. You can configure different systems as IdP, for example Microsoft Active Directory, Oracle Internet Directory, Google, Salesforce etc.
  2. IdP initiated Login and SP initiated Login: When a user needs to access the application, he/she can initiate the access in two different ways. User can logon to IdP and then from there, click on links to access other systems (i.e. SP). This is called IdP initiated login. Or otherwise, the user can go directly to an SP application to access the application. In this case, SP will redirect the user to IdP login page where user will provide his or her username and password, IdP will authenticate the user and pass the control back to SP asserting whether user is authenticated or not. SP will then allow user to access the application

With Salesforce, you can configure Salesforce both ways – as an IdP or as a SP. There are different possible combinations in setting up SSO with Salesforce.

This post will provide you step-by-step guide to setup Single Sign On with Salesforce in different ways, enabling you to actually try it out yourself and understand the nuances of it. It is one thing to read about SSO or watch a video and understand its concepts. However it will be a different experience all together once you have configured it yourself step-by-step.

1. Microsoft Active Directory as IdP and Salesforce as SP

In the first scenario, you will be setting up a Microsoft Active Directory on Amazon Web Services (AWS) as Identify Provider and then use this to allow users to logon to Salesforce. Salesfoce in this scenario will play the role of Service Provider. Don’t worry if you do not know how to setup Microsoft AD and AWS. With this step-by-step guide with screenshots, you just need to follow the instructions. This step-by-step guide includes how to

  • Configure Windows 2008 Server on AWS
  • Install Microsoft Active Directory
  • Install Microsoft ADFS 2.0
  • Create self-signed certificate in IIS
  • Configure Microsoft ADFS 2.0
  • Export Self-Signed Certificate
  • Retrieve ADFS 2.0 Details for Salesforce Configuration
  • Configure My Domain in Salesforce
  • Enable SSO in Salesforce
  • Add Salesforce as Trusted Relying Party in ADFS
  • Configure AD User for Single Sign On in Salesforce
  • Test SSO
  • Use Just-In-Time (JIT) Provisioning
  • Debug SSO Issues

Not an “All Access” Pass Member Yet?

Get Download Access to this & 150+ More Step-by-Step Guides with “All Access” Pass. A simple and single plan to access our entire library of courses, guides, workshops & masterclasses on Salesforce.

Do let me know if you were able to get SSO to work following this guide with your comments, feedback and suggestions. If you got stuck anywhere and were able to resolve the issue, mention that as a comment so that others can benefit from your experience

References & Useful URLs

  1. https://developer.salesforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services
  2. https://ap1.salesforce.com/help/pdfs/en/salesforce_single_sign_on.pdf

15 thoughts on “Step-by-Step Guide to Build Your Own Salesforce Single-Sign On ( SSO ) Test Lab”

  1. Hi Ashish,

    Thanks for sharing a useful topic in Salesforce SSO. You have provided SSO configuration in depth. I’m sure everyone will like this blog. There are multiple blogs on SSO where we can log in to Salesforce from an external system(AWS, Facebook, or Gmail), but I don’t see any blog for login to the external system from Salesforce. For example, if I have a website and I want to open this website from Salesforce with SSO implementation. Is this a feasible solution with Salesforce?

    Use Case –
    Create a quick action button on the Record Detail page, and if the user clicks on the button, the system should open the portal without credential.

    Regards,
    Puneet Gaur

  2. Hi Ashish,
    Thanks for your great post. I follow the same instruction given in your document. But I am receiving some error in ADFS like \adfs\is\IdPinitiatedLogon.aspx does not exists. Am I missing some steps here to configure ADFS? Also SP initiated SSO is not working. Could you please let me know what could be the issues over here

  3. Hi Asagarwal,

    Can we do SSO implementation without letting user redirect to IDP? Currently it redirects to IDP and then come back to Salesforce.

    Thanks

  4. Hi asagarwal,

    This was simply awesome. I struggled so much setting up ADFS and SSO untill I found your blog. This was too simple and easy to follow.

    Thanks a lot, you save lot of our time.

    ~Cheers,
    DJ

  5. Hi Asagarwal

    Thanks for all the help,only one question more ,How i can view the SMAL Assertion or where i can found SMAL Assertion .I will be very thankful to you .

    Kindest Regards
    Obaid

    1. Hi Obaid, Please refer to section ‘Debug SSO Issues’ (Slide 191 onwards) of the step-by-step guide in this blog post to get details on how to view SAML Assertion. SAML Tracer Plugin in Firefox is a great tool to view SAML Responses sent by IdP to the SP.

  6. Hi Asagarwal
    Thanks for replying,does it possible if you refer me any document that can help me ,because it implement the same rules(through Claims Rule Language in Active Directory Federation Services ) on test environment ,and that is working fine.
    I will be much thankful to you .
    Kindest Regards
    Obaid

  7. Hi Asagarwal
    One quick question ,i follow the same step that you mention ,Everything working fine like SSO ,JIT. But i have one issue when i creat a new user through jit and in Send ProfileId is mentioned as “Standard User”,it creat a standard user ,but when we change the profile id from “Standard User” to “Marketing Manager” in Salesforce. When the user Login next time though Federated SSO it again convert it to “Standard User” from ” Marketing Manager ” . Do you have any idea why this happen ?
    I will be very thankful to you if you help me out from this issue.
    Thanks
    Kindest Regards
    Obaid

    1. Hi Obaid, I vaguely know why you are having the issue. If I am not wrong, whenever a user is getting authenticated through SSO, Salesforce updates the user’s record wth the details received from IdP. That is why the profile is getting reset o ‘Standard User’. To control this behaviour you will need to use “Custom SAML JIT with Apex handler”, which can be set on the Single Sign On settings page. In the Apex handler you can then control which values should get updated and which shouldn’t.

  8. Hi,

    This was an incredibly useful article. Very easy to follow!! The only thing I wasn’t able to get to work was the claim rules for JIT, when I copied the rule syntax you provided, I got the following error

    “The custom claim rule syntax is not valid. POLICY0002: Could not parse policy data.
    Line number: 3, Column number: 73, Error token: “.Line: ‘ =>issue(store = “Active Directory”, types=(“User.UserName”), query = “;userPrincipalName;’.
    Parser error: ‘POLICY0029: Unexpected Input’

    Please note that I simply copy/pasted the rule syntax you provided. Any ideas? Thank you very much!

Leave a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top
Introducing All Access Pass