Amongst the various acronyms and abbreviations in the world of authentication, SAML, which stands for Security Assertion Markup Language, is one of the most confusing. So here we’ll walk through what is involved in SAML SSO and paint a clearer picture of what it actually means.
First, a brief summary of what we covered in a previous post, what SSO actually means. SSO, or single sign on, is when you log in to one account and it gives you access to multiple products or sites.
Probably the most common example of this is a “Login with Google” button, and the idea is really simple. You have an account with google, you’ve signed in to your account with Google, and then you get access to any site that has implemented this button.
With Enterprise SSO, instead of having a personal account with google or twitter or anything like that, you leverage your work account and gain access to all the products that your company uses. These work accounts are managed by a tool called an Identity Provider (IDP). Common IDPs are Okta, Azure, and Rippling.
SAML is a method to achieve this kind of SSO, where a user gets access to the products they need to do their job via their single account with the identity provider.
A SAML Example
Let’s walk through a scenario to demonstrate what this looks like. Say an employee has just joined a new large company as a sales representative. The company knows that this employee is going to need access to Salesforce.
As part of their normal employee onboarding, they are added to the companies Identity Provider (e.g. Okta, Azure AD, Rippling, etc). The employee is then added to a group associated with the sales department. The company marks that any employee in this organization should be allowed access to Salesforce. The company has configured the IdP such that any employee in this group should be allowed access to Salesforce.
From here there are two possible paths. In the first, the employee goes to their IdP employee dashboard, where they have a button for Salesforce. When they click it, they are immediately logged in and brought to Salesforce, since they are already logged in through their IdP.
In the other path, the employee goes directly to Salesforce, and they select to log in with their employee account in their IdP. In this path, it works almost identically to the example we walked through in our post about SSO, but in this instance instead of working with Google, they are working with the company’s choice of IdP. It verifies whether the employee is authenticated, and then sends a SAML response back to Salesforce indicating that yes, this employee is authenticated and allowed access to salesforce, based on the information they already have for this employee.
Setting Up SAML
Now each Identity Provider handles this handshake between various platforms and tools and their own systems in different ways. A nice aspect about PropelAuth is that we provide step-by-step integration instructions so that you can implement SAML SSO regardless of your customer’s IdP of choice.