Set Up Salesforce With Google Single Sign-On (SSO)

Share this article...

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.

Source: Google

Benefits of SSO

For the avoidance of doubt, these are some of the tangible benefits of SSO:

  1. Increased user adoption (seriously, people stop logging in if they find remembering password #87 too difficult)
  2. Reduced admin cost (fewer support requests)
  3. Time savings (5-20 seconds each user, each and every time, and that’s presuming they don’t ever do typos)
  4. 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
  5. License savings (see above point about automatic decommissioning of access to applications)

Pre-requisites

  1. 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.
  2. You should have already enabled and setup “My Domain” on your Salesforce.
  3. 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.
  4. 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.

Strong Recommendations

  1. 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 🙈
  2. You know that the first time you do this, you should practice on a Sandbox or Developer Org, right? 😀

Instructions

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.

Within Salesforce

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.

i.e. https://my-domain.my.salesforce.com e.g. https://naturallyiq-dev-ed.my.salesforce.com

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 23: Suggest to the users that they create a bookmark in their web browser with their Salesforce domain.
i.e. https://my-domain.my.salesforce.com e.g. https://naturallyiq-dev-ed.my.salesforce.com

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.

Epilogue

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 👌).

Credits

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!

27 thoughts on “Set Up Salesforce With Google Single Sign-On (SSO)

  1. Superb tutorial!
    My question is, how would you link each google account to its salesforce user?
    I guess the email set in Salesforce must be one from google (Gsuite or Gmail)

  2. quokkasugarvarda89346

    Reply

    Yes – it’s set for the whole domain (so GSuite is required, not Gmail). There’s a workaround using Federation ID on the User object where you can specify individual email addresses for each person, but that’s where sandboxes come in handy for testing things 🙂

  3. Hi, I am receiving an error that doesn’t leave any logs at Salesforce, even of an attempted login, I can’t seem to get at where to look for what’s cause the problem. I’ve followed these instructions exactly, checked my URLs, all seems fine.

    The error URL is https://pffa.my.salesforce.com/_nc_external/identity/saml/SamlError and the error message is https://pffa.my.salesforce.com/_nc_external/identity/saml/SamlError

    Can you point me in a direction to even start digging for more information to solve this? Thank you!

  4. It’s likely that there is a typo/misunderstanding, so perhaps get a colleague/friend to peer-review for a fresh pair of eyes (that’s my #1 tip). There’s some more guidance here https://help.salesforce.com/articleView?id=sso_saml.htm&type=5, but also post on https://developer.salesforce.com/forums particularly asking for SAML troubleshooting steps. Unfortunately with the information provided it’s not enough to be able to assist further (with my skill set!).

  5. Hi, thanks for this tutorial.
    Everything’s working as intended, however, when I click my org’s URL (bookmarked in the example) I am taken to the Salesforce login page where I have to click on the SSO option, which then automatically logs me in. In your example, no SSO button clicking is required. Couldn’t know why. Any idea?

    1. As an educated guess within the “My Domain” screen, edit Authentication Service, and untick Login Form.You are ok, but for everyone else, make sure your login is working correctly with Google SSO first!! If you need to login with a weird/wonderful/non compliant username later you’ll need to go to https://login.salesforce.com instead.

    2. Hi, would you be willing to help me figure out why mine isn’t working? I’m receiving an error and followed everything I can see exactly, would you be willing to email me at rob at itarsenal.com ? so I can compare what you’re seeing with what I am?

  6. Hi Robert. Unfortunately that’s not possible due to other requirements I have on my time. Google SSO is possible, but is fiddly. I think this is the last post I’m going to reply to on the subject (to help manage everyone’s expectations) BUT I do recommend you reach out to the Trailblazer Community (in all its guises) as that’s what has really helped me overcome any number of technical challenges.

    There’s an amazing bunch of people out there only too ready to help share their experience and knowledge. More details is this great article, just published 😉 https://www.salesforceben.com/the-power-of-the-salesforce-community/ and look out for another one, next week entitled “Networking in the Salesforce Ecosystem” which gives more hints and tips.

    p.s. Sorry for not replying to your first message – I thought I had, but the above post covers the same area of advice I would have given.

  7. One edit here. These instructions didn’t work, and I finally figured out why! The ACS URL is NOT the same as the Entity ID. It is the Login URL from your SAML Single Sign-On Settings page from the step above into the ACS field. This will contain your org Id at the end of the URL This will fix the issue!

    1. Glad to have your input and thank you for sharing. It’s weird. Glad to have your confirmatio – I thought I had seen this previously but wasn’t too sure. This guide was thoroughly tested and has worked for many people but I’m suspecting there’s a setting somewhere (no idea where) that makes a difference as to what value is accepted. Perhaps it could be something like type of Google Account or age of Salesforce implementation for all I know(!)

  8. Does enabling this as described in the article impact integration users? I didn’t see any mention of excluding specific “users” from the SSO requirement. Thank you!

  9. No, as long as you don’t play with other settings on that screen, it won’t affect integration users. This method (as described – other settings are different!) gives you additional login options, and doesn’t take anything away.

  10. I must have missed something big, but how does this work when you’re being smart and starting in the sandbox? The logins in the sandbox are not the same as production since the sandbox has the .[sandboxname] appended to it. I don’t see how the Gsuite email and the sandbox login can match here.

    1. Two parts: You’ll spot a field on the User object which says Federation ID – put the email address there. Within Setup, select SAML Single Sign-On Settings and then SAML Indentity Type: “Assertion contacts the Federation ID on the User object”

  11. Stephanie Stoddard

    Reply

    John, did you receive an answer to this question, either here or elsewhere? I have the same question and cannot seem to find an answer.

  12. John, Stephanie, there is an article that calls this question out that I recently came across when researching the same question: https://admin.salesforce.com/blog/2021/everything-admins-need-to-know-about-the-mfa-requirement

    It specifically calls this out:

    Does SSO satisfy the MFA requirement?
    Yes — as long as all of your Salesforce products are integrated with SSO, with MFA enabled on the IdP, and all users who access a Salesforce product’s user interface do so via SSO. Note that you must use a federated SSO solution based on the Security Assertion Markup Language (SAML) or OpenID Connect standard protocols. Delegated Authentication does not satisfy the MFA requirement.

    Hope this helps!

  13. HI , Thanks for the tutorial ,

    I have followed all the steps but after all , I am getting Single sign-on error “We can’t log you in because of an issue with single sign-on. Contact your Salesforce admin for help.”

    Please assist

    1. Got the same error Raman … it’s very frustrating. Also frustrating is the initial Salesforce setup where it takes 24 hours before you can even test.
      Would be nice if some screenshots of Google setup were included and not just the Salesforce side.
      Did you get it working? We are still stuck.

  14. What would really help is a screenshot of what’s in Google and not just what’s in Salesforce
    A screenshot would possibly have picked up on Brian’s comment – I think we may have made this mistake

    Brian Rauch
    November 5, 2020 at 4:11 pm
    One edit here. These instructions didn’t work, and I finally figured out why! The ACS URL is NOT the same as the Entity ID. It is the Login URL from your SAML Single Sign-On Settings page from the step above into the ACS field. This will contain your org Id at the end of the URL This will fix the issue!

  15. Stephanie Stoddard

    Reply

    I want to use my SSO configuration for portal users as well. How do I configure SSO in Google to allow for standard Salesforce users and portal users to use the same SAML SSO? When I try to login as a portal user using the Google App, I get this error: “Failed: Invalid Portal ID”, and the Login URL is for our production org, rather than the portal URL. I am not sure how to pass the portal ID to Google, and also how to tell Google which users need to use which URL to login.

Add Comment