The Developers Speak is a video series featuring certified Salesforce consultants at Digital Mass. They come to you twice a month to help bridge the gap between business problems and technical solutions.
On this episode of The Developers Speak, Tom goes over what Salesforce Single Sign On (SSO) is and how it works. He also shares a tip about how to make it work "in the wild".
Hi everyone. I'm Tom, and I'm a Salesforce developer at Digital Mass. And today I'm going to talk about Single Sign-on in Salesforce, what it is, and what benefits it can offer an organization that implements it. Single sign-on is a method of authentication that allows a user to have one username and one password and sign into, you know, several independent software systems or applications without needing to have an individual username and password combinations and authentications for each of the different systems. Single sign-on can really prevent a lot of headaches for an organization and a user when it comes to memorizing and managing all those username and password combinations. You know, so think about if you have 20 different applications that you need to sign into in your organization, that is a lot to remember, especially if your organization's security policy requires that you change passwords every 90 days. Single sign-on is wonderful for both your security team and your users because all you need to do is memorize one username and one password combination, and then you can sign in to everything. Any organization that uses Okta or Microsoft Azure can easily set up Single Sign-On with Salesforce.
The actual technical steps for Okta and Azure can both be found in the documentation for those specific apps, but any identity management system can interface with Salesforce. Typically when you're out in the wild, most organizations will only have the use case of meeting their own users to log into their own Salesforce instance. But I have encountered a case where an organization had many external users that were affiliated with many different organizations and they all needed to sign into an experience cloud page that my clients owned. And so the secret sauce to this, which was not covered in any of the documentation is to take the login URL for your Experience Cloud page and swap that out with your Salesforce instance URL and all of the spots in Okta or Azure that would require your Salesforce instance. So just put in your experience cloud login page in every slot, except for the audience restriction that you can keep as your Salesforce instance. So I hope you learned something about Single Sign-On today and how great it is for an organization. And a lot of organizations are moving in this direction, so it's a good idea to get prepared and learn how to set it up. If this video helped you like the post or share it with someone who might also find it interesting. Thank you.
About the Developer:
Meet Tom: Salesforce Developer and full-stack star.
After graduating from the University of Minnesota with a BS in Computer Science and working as a Software Engineer, Tom was looking for a new opportunity that would spark his love for the field again. So, he decided to spend some time on Trailhead and realized he had a knack for solving Salesforce problems: they were challenging, fun, and he could zone in and focus on them for hours at a time.
Once Tom joined our team in February 2021, he decided to get his first certification Platform Developer l. Next up is Platform Dev ll! 🚀
When his hands aren’t on the keyboard, he spends as much time outside as possible and away from screens, especially in the Summer months when he can hike around the nature preserve with his friends.