One of the more tedious jobs as a Salesforce admin is resetting user’s passwords. Even though there’s a button on the Salesforce login screen which says “Forgot your password”, some people don’t notice it.
If only there was an easier way?
Introducing Single Sign-On
The concept behind Single Sign-On (SSO) is easy: sign in to one system, and then be automatically signed into all the rest of the applications you need. Fewer passwords, fewer headaches, less tedium and it should enable you to get on with what you actually intended to do, rather than get bogged with admin stuff such as hunting around for where you put your password hint*.
*we recommend looking at either Password.docx or the yellow post-it on top of the laptop.
The best implementations of SSO seem to work by magic. The user shouldn’t even notice that it is there, it’s just seamlessly passing your login validation from one system to another without any end user intervention. But that costs a lot of money to set up, right? Not necessarily.
In this guide, I’ll be walking you through a basic out-of-the-box setup, showing that if you use GSuite (i.e. the business edition of Gmail) your users never worry about their Salesforce password again.
It’s worth noting that there are other types of login, such as:
- With Salesforce, or another system entirely (such as LinkedIn or Facebook), as the lead
- Where user management is also enabled, allowing an admin to create a user in one system (such as GSuite or Microsoft 365) and it automatically creates the associated account in other systems (such as Salesforce)
- Password-less systems such as Lightning Login
Check out Martin Humpolec MVP’s blog for more details about each of these. They all have pros and cons: in terms of features, ease of use, user account management and some are more fiddly to set up than others.
Benefits of SSO
For the avoidance of doubt, these are some of the tangible benefits of SSO:
- Increased user adoption (seriously, people stop logging in if they find remembering password #87 too difficult)
- Reduced admin cost (fewer support requests)
- Time savings (5-20 seconds each user, each and every time, and that’s presuming they don’t ever do typos)
- Improved security (one policy; not multiple sets to align), and users will be quickly and automatically removed when they leave as long as the lead system is updated
- License savings (see above point about automatic decommissioning of access to applications)
- You need to be both a GSuite and a Salesforce admin to accomplish this mission, or be on good speaking terms with the relevant administrators.
- You should have already enabled and setup “My Domain” on your Salesforce.
- The first time you try this, please use a Developer Org or Sandbox. I’ll be using a Developer Org which is why some of the URLs will look a little strange.
- For the sake of the example we will be walking through, your organisation’s email addresses must be the same as your Salesforce production org usernames. (e.g. GSuite account is [email protected] and Salesforce username is also [email protected]). In real life this doesn’t need to be the case as there are easy workarounds.
- Most people have more than one Google/GSuite account these days… For your sanity, on your computer, I recommend you use Incognito Mode on your browser; just log into the GSuite account where you are both the Administrator, and wanting to connect that org to Salesforce. Otherwise Google will keep on trying to push you into the Admin Console of your first-listed account, potentially with undesirable consequences 🙈
- You know that the first time you do this, you should practice on a Sandbox or Developer Org, right? 😀
Within Google/GSuite Admin Console
Step 1: Go to your GSuite Admin Console and login: https://admin.google.com/
It will look something like this:
Step 2: Go to APPS (the multi coloured square on the screenshot above) and then to “SAML apps“.
Step 3: Click on the “+” in the bottom right hand corner.
Step 4: Use the Filter box that appears to select Salesforce or Salesforce Sandbox (depending on what you are connecting to).
Step 5: On the following screen download IDP metadata by “2nd option” (see pink highlight on screenshot below).
Step 6: Press “Next” and leave where you are as it is, and open up a new tab. You’ll come back to it later.
Step 7: Navigate to Setup – Identity – Single Sign on Settings (or, within Setup, type “Single” into either of the search bars)
Step 8: Click “Edit” (highlighted in pink, in the screenshot above), check “SAML Enabled” and click “Save”
Step 9: You’ll then be returned to the previous screen (same screenshot, above).
Step 10: Click “New from Metadata File” and choose the GoogleIDPMetadata XML file you downloaded in Step 5 and then click “Create”.
Step 11: On the next screen (see screenshot below) you will just want to change the “Name” and “API Name” to something meaningful; this will also be displayed to your end users who are logging in. Don’t worry too much though – you can come back and change the Name and API Name later on, without impacting anything else.
Tip: I tend to go for Company Name + GSuite (e.g. “Naturally IQ GSuite” / “Naturally_IQ_GSuite”) as, inevitably, if if I just put “Google” or “Gmail” some people will mistake it for a search engine shortcut or their personal email account.
And then press “Save”… so not much to update on this screen despite all the red text and red lines; you do not need to choose a file for Identity Provider Certificate even though there’s a red line against that item seemingly indicating that it is mandatory.
Tip: This screen is worth exploring for yourself later, as it allows for lots of customisations, whether that’s flexibility around username formats (“Federation ID on the User object”), logout screens (“custom logout URL”) or generating user accounts on the fly (“user provisioning enabled”).
Step 12: This is the screen that you get when you press “Save”. Make a note of the Entity ID (e.g. copy it into Notepad/computer memory) as you’ll need it for Step 14.
Within Google/GSuite Admin Console again
We’re continuing on from Step 6 here, where you’ll be on a screen saying “Step 3 of 4”.
Step 13: Press “Next” to continue to “Step 4 of 4“. You’ll see a screen like this:
Step 14: These are the details you’ll need to fill in:
- Signed Response: Yes / Tick / True
- ACS URL: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).
- Entitly ID: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).
- Start URL: The “Entity ID” from the previous SAML Single Sign-On Settings screen (see Step 12).
Yep, all those three entries require the same information.
Make sure your Entity ID field is copied EXACTLY from the Entity ID field in your SAML configuration in Salesforce in Step 12.
And that Entity ID, you may recognise it from somewhere else….
Tip: By default the Google example will have a slash at the end of the Entity ID URL while Salesforce does not use this. You need to use the one that Salesforce gives you. Also, Google says to include your org ID for the ACS (e.g. https://naturallyiq-dev-ed.my.salesforce.com?so=00D4J000000abcd) but I’ve found that is no longer necessary and including it can cause new SSO setups to fail.
Step 15: It will look something similar to the screenshot below (just with your own org’s details):
Step 16: Click “Finish“ and you should see the following confirmation message:
Step 17: Press “OK” and you’ll be taken to Google Admin Console’s SAML Apps’ Settings for Salesforce screen (see screenshot below).
Step 18: Click “Edit Service” (highlighted in pink, on the screenshot above), select “ON for everyone” and then press “Save.”
Step 19: Yes, this change really can take up to 24 hours, even for small organisations. You still need to complete a few more steps (see below), but in the meantime our very own SalesforceBen gave it a try, may not have waited all of the 24 hours, and got the following screen:
When he came back later, having waited the whole 24 hours, it all worked without any problems.
So, grab a coffee and then consider documenting this change that you are making. Especially reference the “Epilogue” section of this guidance as you’ll have to do some annual maintenance.
Back in Salesforce
Step 20: Navigate to Setup – Company Settings – My Domain
Step 21: Click “Edit” by “Authentication Configuration” (highlighted in pink, on screenshot above)
Step 22: Tick the “Name” that you chose earlier (in my example it was “Naturally IQ GSuite”). Consider coming back later and unticking “Login Form” (see tip below), but make sure everything is working first!
Tip: Unticking Login hides the “login” box (asking for Salesforce username and password) from the user’s initial screen and is a wonderful piece of decluttering, but doesn’t actually remove it as an access method; users can still login via customised URLs. To remove the option of users logging in with Salesforce credentials entirely, you need to log a case with Salesforce Support to enable Delegated Authentication. This way Salesforce always logs in via GSuite, so the account has to be active there, before logging in, further improving security.
Step 24: Actually we’re done but do read the Epilogue as annual “maintenance” will be required.
What it looks like in practice
Ellen logs into her Gmail.
Ellen clicks on her specific-instance Salesforce bookmark (e.g. https://naturallyiq-dev-ed.my.salesforce.com).
After a few, short, automatic browser redirects, Ellen gets the following screen:
Tip: If Ellen happened to have more than one GSuite or Gmail account open on her computer, she would have first seen a screen asking her what account to use. It would have looked like this:
Clicking on the correct (work) account would have then taken her into Salesforce.
After a period of time, perhaps one or two years, you’ll receive an email about “SFDC Expiring Certificate Notification” in your inbox.
It is easy to fix!
Step 1: Within Salesforce’s Setup, go to Single Sign-On Settings within Setup, then click on the SAML Single Sign-On Settings you created previously
Step 2: Check the certificate name matches the one you received an email about (otherwise the issue is elsewhere).
Step 3: Go to Certificate and Key Management (within Setup) and click “Create Self-Signed Certificate”
Step 4: You can now create your new self-signed certificate (and give it a better name!); click “Save” at the end.
Step 5: Pop back to the SAML Single Sign-On Settings screen in Step 2, click “Edit” and choose your new certificate.
Step 6: Press “Save” and all done! (well, perhaps give it a test to check that the Single Sign On login is still working 👌).
Huge thanks go to Ben McCarthy, Marie van de Roekel, Mariella Brodersen, Martin Humpoec, Patrick Connelly and Puneet Mehta for their technical guidance, proof reading skills, putting this blog to the test and, most importantly, time!