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
- Federated Authentication using SAML
- Delegated Authentication
- 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.
- The concept of IdP/SP
- The concept of IdP initiated login and SP initiated login.
Let’s try to have a basic understanding of these two concepts
- 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.
- 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
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