Lawrence Newcombe, who joins to talk about SSO in Salesforce, is the Lead Technical Architect at Giveclarity.org and Salesforce CTA.
Main Points
- What is SSO
- The role of Salesforce in SSO
- The Salesforce certificate that covers the SSO topic
- Lawrence’s blog to share his Salesforce knowledge
- SAML SSO
- OpenID SSO
- Debug SSO
Links
- Lawrence’s LinkedIn
- Lawrence’s Twitter
- Lawrence’s blog
- Blog: Service Provider initiated SSO
- Blog: OpenID Connect
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:14] Hi everybody. This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today I'm sitting with again a new guest. His name is Lawrence Newcombe. Hello, Lawrence. Hello, Xi. Great to be here. Before starting, would you like to still introduce yourself? Thanks, Xi. So, so I work as a lead technical architect for an organization called GiveClarity.org, which is a Salesforce implementing partner and ISV focusing on the the nonprofit space, predominantly, predominantly fundraising. So, we help organizations of all sizes, up to some really big. Sort of global organisations to to improve their capabilities and capacities around using activities. So, so lots of lots of salesforce work, lots of core platform, lots of marketing cloud projects, analytics, and we a lot of our lot of our projects also use use Salesforce NPSP. So we we see a lot of see a lot of activity around NPSP in the in the community as well. So Lawrence, did you mention you are also a CTA? I
[01:22] skip that bit, but yes, I've been a CTA for about the last two and a half years, I think, something like that. Yeah, congratulations. Maybe it's too late, but yeah, to have you on on the show. Thank you. In this episode, we want to talk a topic. It's named SSO, the single sign-on. So, could you still briefly define what is SSO? Sure. So, I guess in a nutshell, so single sign-on is about using the identity that a user has established in a a in in an application. So, typically in in the context of of of Saml single sign-on, that would be called an identity provider application. It has sort of slightly different reference terminologies depending on the framework that we're we're talking about. But let's kind of consider identity provider. That's kind of quite. Kind of useful descriptive name, so the the we it's so single sign-on is really about the opportunity to use. A user's identity in that application to authenticate to other applications. So, for example, it might be that we. A user's identity in Google is being used to authenticate authenticate that user in a ServiceNow account or a Salesforce account or any number of corporate or non corporate applications that need to know who that user is and know that they are authenticated
[02:52] and able to access access those those applications. I mean, even without knowing the concept, still people have been using SSO for so many years. You know, I remember it's definitely more than ten years ago. The first time I I went to a forum, a online forum, like the text based some threads. And people are discussing there. And I just saw one day, I can log in via Google account, log in via a Facebook account. That was the first time I encountered SSO. I was like, such a brilliant idea! It seems like magic the first time. Yeah, indeed, it's like, wow! How did you do this? But it was really smart. I don't need to remember anymore or create a new account, right? I was like automatically signing with my my Google account. Especially in my own machine, my Google account is automatically signed in. So whatever other website I go to, it can always use my already signed in Google account to authenticate, which is really really convenient at the time. Yeah, yeah, and it's it's it's a great point, and actually, there's because there's there's really sort of two sides to why SSO is is a great thing, and. And and one of those sides is really about the the user experience. So so why why is it as an end user, SSO is great. It's it's it's exactly that. It's that that sort of sense of or that convenience
[04:22] really of having that sort of single password, that single authentication method that basically gets you in into multiple places. Ideally, everywhere you need to go within a within a corporate environment. Let's talk those things through here. Especially, I'd love to hear like how SSO is is used in in Salesforce ecosystem. And also, you know, I was working in the consulting area. I know a lot of customers, especially when they nowadays start use Salesforce, they already want to the SSO to be enabled at the day one to get all these benefits. So, so how do we use SSO in Salesforce? Yeah. So there's there's a few options, and I suppose before going into those specific options, it's worth. Mentioning as well that even even the role that Salesforce can play can can be quite different. So, Salesforce is often used, or often will play the role of a single service application in in an an IT estate. So, there'll be an identity providing application that that authenticates users into Salesforce. So, that's a very common common setup. So, and the sorts of identity providers you might. Sort of typically seen in in those environments are things like Okta, Ping Federate, OneLogin, but also even you know even even sort of Microsoft as your Active Directory or AD FS. Google Workspace, so these these sort of environments that are used for multiple
[05:53] things often can act also act as as a source of identity as well. So in that context, Salesforce can play the role of a service provider being and have it have the authentication being done by by those identity providers. So you mentioned some names just now. I would assume. For medium or large organizations, they have already on their enterprise architect level. They have already identified some identity management system. For example, they might say, "We want our entire organization. We want every users to use the Microsoft AD." Once they have already defined that, then once they start to use Salesforce, so they want Salesforce to also use the same identity provider to authenticate the user. Seeing, yeah, that's certainly very common. Yeah, coming to as you say, medium and larger organisations will tend to have a policy in in place if they, yeah, if if if they which. Typically, Salesforce will need to comply with that, rather than necessarily dictating what that should be. Okay, got it. The the other context that so, or I suppose the other role that Salesforce. Can play in some circumstances is is actually acting as the source of identity in itself for other systems, other applications. So in in that context, so. Users will be logging in to other applications via their Salesforce user accounts. So that's that's something that can be quite helpful to
[07:23] to set up in, for example, in multi-org situations. So if users will require access to more than one org as part of their job, we can set up single sign-on between those orgs. In so it's sort of often referred to as a hub and spoke. Model where there is a single hub org that controls the the identity authentication for that for for for the users in in the spoke orgs that can simplify simplify the account management for for those users. It's also quite helpful in in community scenarios. I worked worked on a project. Where we had a community for a network of partner staff, and those those all of those partner staff required access to a training portal as well as their Salesforce community. So we were able to to provide that in quite a seamless way by establishing single sign-on from the the training system into Salesforce. So so it's quite a a sort of straightforward, seamless experience of moving between those systems for for those those those partner staff, and they probably weren't even aware that they had two different user accounts. From their perspective, they had a single. Single login to remember that was all of their access to the systems that they required as part of that that arrangement. How should I study that? When I look at the Salesforce the certificate pyramid, I would assume it sits on the
[08:53] right side, which is a system architect. Yeah, that's right. So there is an Identity and Access Management Architect certification. I think it's called these days, which is yeah, very much focused on on what what you need to know really around setting up single sign-on in various contexts, and also authentication and authorization considerations for for OAuth flows as well, for example. But if a person wants to study further to the CTA, does they need to dip deeper into the website? It's a great question. I guess the answer is probably yes. There's certain quite specific things that tend to be asked about at CTA review boards. So, for example. It's fairly seems to be fairly common, commonly asked for for candidates to draw the flow of a a single sign on mechanism that they've recommended as part of their solution or or a or You know, and authorization code flow, for example, if that plays a part in their solution. So there's a slightly sort of different slant to the information you need to have immediately to hand in your head for Salesforce. And now, Lawrence, you have your personal website where you share topics of Salesforce-related diagrams or architects. Is SSO also part of the information? Yeah, yeah, that's that's right. So, so, so yeah. So SSO is is quite quite a big part of that. And so the the focus that I've tried to kind of cover on
[10:24] on my website, so CloudSundell dot com, is is is really about sort of authorization and authentication considerations for Salesforce in in general. Of which single sign-on is is kind of quite quite a big part of that, and then various different all flows that Salesforce can participate in are covered in on on there as well. So it's worth just just for complete transparency, I was by no means a identity Salesforce identity whiz at the time that I started studying for CTA. So most of the materials actually that are on that site. Kind of started life as my study notes, really for for CTA and trying to, you know, myself really kind of build up to that level of knowledge that you you you do need to be able to demonstrate at the board. So so they are. Well, I wouldn't say that it's entirely focused around CTA preparations. That was kind of how it started life. So so yeah, hopefully it's it's useful for others in that in that way as well. Yeah, we appreciate you share the knowledge, you know, and also those diagrams. I've had a look, so a lot of diagrams definitely they will help us to. To build the knowledge in our mind easier than read a lot of text, and yeah, I will put your sites and maybe SSO related articles specifically also into our show notes, just for our listeners to check. Great, thank you, Xi. But now here, I also want to study a bit of SSO rather than only on the concept level. So how how can I learn from you? Well,
[11:54] I've got a I've got a proposal. If you'll play along with me, she. Sure. So I thought what might work to help illustrate some of the specifics about actually what's sort of happening behind the scenes during during single sign on interactions. For the purposes of this, I like if you'll join me. I'll play the part of Salesforce, and you play the parts of Google. Okay. I'm happy to be as Google. At least for half an hour. Great, thank you. I mentioned there are different protocols and different methods that that salesforce can employ around single sign on. So I thought we could kind of explore the the two main ones. So a as Saml based single sign on flow that is probably sort of the more common one that you'll see in authentication between corporate applications, and then after that we can look at a alternative version of using the Open Identity Connect protocol. Sure. Let's get it rolling then. Okay. Thanks. Okay. So in our first example, so as the identity provider, so in in both cases, Xi, you're going to be playing the part of Google, but you're actually going to be a slightly different flavour of Google in each one. So. In our Saml based flow, you're going to play the part of a Google Workspace. So Google Workspace is effectively kind of Google's corporate product. That
[13:24] if you sort of use Google at an organisation, you're likely using or a corporate account, you're likely using Google Workspace. Whereas in the Open ID Connect, you'll be playing the part of the consumer Google service, and that that actually speaks to one of the sort of key differences between between the two mechanisms that we'll come onto in a moment. So the first thing that we need to do as part of getting ready for some sample single sign-on is we're going to have to agree between us between Salesforce and Google Workspace the the configuration parameters that we'll be using to to communicate with with each other. So first of all, I would want you to tell me the identity provider login URL for the for for you as the sample application in Google. So I would assume it's like Google dot com slash something. Yeah, I think it's something something like accounts dot google dot com slash. Something slash there'll be a Saml too in there somewhere, but effectively it's a it's a URL which which allows me to as Salesforce to send an authentication request or as well as as a Saml request to the. Correct Google Google Workspace Saml app so that you can then manage the process of actually authenticating the user. That's like the first endpoint. That Salesforce can reach to talking about. Yes, yeah. So that's a bit of information I just need to know and have configured in
[14:54] in my Salesforce org. I'm also going to need to know that you're effectively kind of your identity as as Google. So so we call this the the issuer. So this comes as a parameter. In the in the Saml assertion that come that you'll be sending me sending me back, and I Salesforce will be using it to ensure that the Saml assertion is is it or to to know where the Saml assertion is coming from effectively. Okay, and then there's a bit of stuff that you need to know as well as the. Google Workspace app, so I'll need to tell you my what's called an Assertion Consumer Service URL. Bit of a mouthful, so it's normally abbreviated to ACS URL. Okay. Which is effectively, it's the URL which you'll be posting the sample responses back to, in in Salesforce. So I have to store that information in my site in the Google Workspace site. That's right. Yes, I also need to let you know my entity ID. So this is kind of the equivalent of your issuer. This is my. It's a string that I'll be using to say, "Hey, this is me." That's the unique ID. Yeah. Okay. Yeah, exactly. And we'll also need to agree how we are between us identifying which user we're we're talking about. So so when you send me sample assertions, those assertions are going to include a reference
[16:25] to a user who you've authenticated. Now you're not going to be sending me any passwords or any sensitive information like that. What you'll be sending me is effectively what I need to know to identify that user. So that could be often it's it's an email address, particularly in this sort of circumstance where Google's in control of the email address. That usually makes sense. It could also potentially it could be a Salesforce username, or it could be a Salesforce user ID. But the important thing is it's something that we can both access that allows us to correlate correlate who the who the user is. Hmm. Okay, got it. Okay. So, so let's jump into the flow. So we've got all of our configuration. Ah. So what we we have just done is that between the two roles, we have kind of exchanged the information so that we we have prepared us for the future. The flows that's going to happen when the the user authentication starts, right? Yes. See, it's useful to pick up on the fact that yeah, we've had to do something in both systems. So I've had to steal some things about Google. You've had to steal some things about Salesforce, and that that's kind of one of the core tenets about about using using Saml is there is configuration required. You know, the company's instance of both systems. Understand? Okay. All right. Okay, so in terms of what actually happens now that we've got all of that set up, so let's let's think. Okay, so a user wants to
[17:55] go to a page in Salesforce. So, so let's let's imagine. So I, a Salesforce, I receive a page request for a user's clicked on a an account record link, for example. Maybe they got emailed a link, they've clicked on that link. Let's imagine they're not actually logged in at the time. So, as Salesforce, I recognise that they don't have a session with me with Salesforce. I'm going to redirect that that user from rather than obviously showing them the account page, which which I can't do yet. I'm going to redirect them to the the Salesforce login page. That page is going to well, depending on how we've got it configured. But let's imagine we have maybe there's a there's a login box there. They could use a username and password, and then separately there's a login with my Google account button. Yeah, the user could then click that button. Of course, then I'm what I'm going to do is I'm going to find the IDP login URL that I have configured for Google, and I'm going to redirect to that login URL with. A couple couple of bits of information. There's going to be a Saml request in in that redirect. So that Saml request is kind of a formal sort of XML. Format request that kind of mentions all all the things that are sort of important about who I am and the the expectations around sort of the Saml protocol that's used and that that sort of thing. But yeah, the
[19:25] probably the most important bit that we kind of need to know now is that I'm going to put in the issuer field of that Saml request a sales source. I'm going to put my sales source entity ID, so that's going to identify that this Saml request has come from me. So then, I as Google, I would receive this request. This request with XML content coming from you, the Salesforce end, with this identity to identify where exactly it's sending from, right? Yes. Yeah. Exactly. I'm also, as part of that request, I'm also going to put as a what's called a relay state parameter. I'm going to put the representation of the URL that the user actually clicked on. So we're going to basically send this relay state back and forwards between us, so that eventually, at the end of the flow, I'm going to be able to serve. The user, the page that they originally clicked on. Ah, it's just to facilitate the user. Once the authentication is done, then he still redirects back to the original link that they came from. That's right. Yes. Okay. Yeah. Now, so the user is redirected to the Google Identity Provider login URL. So I'm supposed to do something now.
[20:45] So the first thing you'll need to check is: is is the user logged in at Google? Probably not. I would assume that the user is not logged in. So then, I should redirect the user to the Google login page. Am I right? Yeah, that sounds right. Okay, and then the next step, the user would type in his credential, and let's assume that's the correct credentials, and then. Google in my database, I can really see this user log in successfully. I assume that's the part. I confirmed the user information. I can then somehow compose the the XML XML response back to Salesforce. At the moment, exactly. Yeah. So so you you'll be constructing what's called a XML assertion, which is yeah, as you say, it's the XML response that represents. What I, I as Salesforce need to know to to serve yeah to authenticate or consider that user authenticated in Salesforce and to serve serve them secure content. You also mentioned the most important thing, of course, is the the unique identifier for the user. Let's let's try to use email here. But I can, in case I want, I can attach additional information of the user. Exactly. That's right. Yes. Yeah. Exactly. So there are a few other things in that assertion, but yeah, like like you say, that's kind of a really key part
[22:15] of it because that's that's how I'll correlate that to to the right user. Okay. So you you'd also including that the as the issuer for that sample request, you'd identify yourself as as the Google app.
[22:29] You would you'd also indicate the recipient as as me as Salesforce, and so the identity ID for Salesforce. So I as Salesforce should only should only be able to consume a a Saml assertion that is intended for me. So. So it has the recipient. So the the effect of that will be that the user is is basically redirected back to Salesforce, and oh, and so specifically back to the Assertion Consumer Service URL. So, ah, yeah. So that's that's basically the URL at Salesforce, which will manage kind of incoming SAML assertions. Salesforce. I'm going to check that that assertion is from someone that I trust. So there's two things that I'll check as part of that. I'll check the signature. And so, so you, as Google, you would have also signed that assertion with the certificate for the app. And I'll also check that the issuer matches matches a configuration in in Salesforce. I'll check, of course, that it's intended for me as the recipient. And I'll find the user and Everything all checks out, which I'm sure it does. Then the Salesforce, I can trust that that person is logged in, and I can trust that I'll issue a session to the browser. And finally, I can take the relay state that would have also been returned and redirect the user to that account page that they wanted originally. Okay, so that's the final stage: the user successfully authenticated in in Salesforce and then redirected to the correct account and page. That's right. Yeah,
[24:00] but I would assume that Salesforce also has a user record for the specific logging user, right? Not only on the Google side, but also on the Salesforce end. There's a matching user record. Oh yeah, often that will be will be the only supported scenario. So so yeah, that's that's certainly often the case that the user has, and that we're able to find a match. It's possible also we can set up a what's called a just in time provisioning handler, so that we can actually kind of configure logic to run at the point that we receive. A sample request that has a user that we haven't seen before. So, so that kind of just in time provisioning, as you would imagine from the name, and that's a way that we can actually create users on the fly in Salesforce based on what we're being told by by Google. So that that is an option as well, or otherwise, if we if we don't have that setup, you know, and which you know maybe maybe preferable in a lot of circumstances, we can just just sort of fail that that login as well. Okay, you mentioned the just in time provisioning. I can definitely see that there are like pros and cons. Like the pros you just mentioned, the admins don't need to always provision a user in advance before the user signs in. But of course, on the other side is that there might be too many users.
[25:30] Maybe they use Salesforce for one time and then you create the user account. That's too much hassle, maybe. Yeah, it could because things could certainly get out of control quickly in in some environments. Yeah, another one that actually is often one that's that's sort of easy to easy to overlook is actually the process of deprovisioning. So it's sort of all very well, you know, having that person set up, set up and ready to go in Salesforce, but without you know that explicit sort of tying together between the Salesforce accounts and the Google account, that there isn't a mechanism. Through, you know, through through just the the sample interaction to actually deprovision that user. So that's why. So with with a lot of identity providers, certainly all of all of the the major ones, the provisioning and deprovisioning processes will be handled. You know, through through API calls or through through a different mechanism, which yeah ensures that that deprovisioning side is covered off as well as the as well as the provisioning. There's there's another consideration as well, and it again it depends a lot on how how things are set up from a permission point of view. But we need to, of course, as part of setting up a user, there's various things in Salesforce that may or may need to happen, or it might be important that they don't happen in relation to permissions. So we need to be confident that that person's being set up with the right profile, with the right role. Potentially with the right permission sets, permission set groups, and all all the other things that go into configuring a user record correctly. Now Google might. And and there are ways
[27:00] to send through specific attributes from from Google that represent information about the user. So it might be that actually we have all the information we need in Google to be able to translate that. Within the just-in-time provisioning handler to set the user up correctly in Salesforce, but often there will be some detail to that that won't be available in in Google or the equivalent. So, so yeah, that's that's that's important to think through as well. I would kind of assume if organization is the first time to configure the SSL for Salesforce, maybe we start from the baby step. We just enable SSL. We don't use the just in time feature. And once the users are are get used to that, then we are thinking about step two. Yeah, yeah. I think that's that's not. Yeah, that's normally the best way to start is is yeah, getting getting is simply the single sign-on element set up and and yeah, provisioning can can come later potentially. Okay. So I guess we have just covered the SAML SSO side, right? You also want to introduce me the Open ID SSO? Yeah, yeah, that's yeah. Open ID Connect. So as as I mentioned, so Open ID Connect is effectively an extension to the old specification. So again, I'll be playing the part of Salesforce here. So, and in this case, she. So, you're. Let's imagine we're now kind of not in sort of a wholly corporate environment, but we're.
[28:30] What we want to do is we want to trust the identity within a user's own personal Google account. Yeah, I mean there are various ways that we can use Open ID Connect, but this is this is one of the circumstances where it's particularly useful. Is you know there isn't necessarily anything in Google that we as an organization have the ability to configure or to control. Yeah, because I I kind of assume if we are using the Google Workspace because we are the paid customer, we have an instance in Google side that our Google admin, let's say in our company, can configure there. But it's if it's the consumer endpoint, then it's it's up to everybody to use in the world. So you definitely don't have control. Yes, yeah, yeah, that's right. And one of one of the circumstances you see this come up a lot for Salesforce is in the context of what's called social sign on, which is sort of more often used for community access. So it might be that we want to allow for users to sign up to a community using their Google account or using their Facebook accounts. Thanks. Yeah, got it. And yeah, again, this is sort of one of the key differences, sort of conceptually, between the two. Is whereas in the Saml, you had knowledge, of course, of all of the users in the Google Workspace app. In in this this version, the authorization is is actually it's actually the user in control of their own authorization as to whether their details are sent
[30:00] to Salesforce or not. So that's that's facilitated through the through the standard sort of OAuth consent mechanism. I think I've seen this many times when the user use this OAuth or this Open ID authentication to log in. There's a page in the middle of login ask the user you are about to grant this information to the the service provider. Would you happy to do that? Accept or not? Right. Yes, exactly. Yeah, yeah, that's exactly. So it starts starts in a similar sort of way. So let's pretend now that it's in a Salesforce Community. So maybe they click kind of a page in a community. A Salesforce. I'll recognise they're not logged in to that community. I'll show them the the login screen that allows them to click the button to sign in with Google. At this point, I'll I'll then redirect to to Google's authorization endpoint. So this is something that is for a service like Google. There's there's a number of services that are pre-configured as auth providers in in Salesforce. We can also add add our own for any services that aren't there. But Google is an example of one that's already pre-configured in Salesforce. So the authorization endpoint that Salesforce already know for Google, the request would be, or I could I could redirect to, and there's there's a few things that I'll, Salesforce include in that, but one of Sort of the main ones is what's called the redirect URI. So this is effectively where where you as
[31:31] as Google needs to send the authorization code that I'll. Then afterwards, use to to get the the access token the the identity token for for that user. I'll also be including sort of scopes, and so it's important that when you mentioned around the approval. So scope is kind of the technical word for the things that the user is approving access to. So so we'll typically want to send a scope that represents the the identity token, so that. The user is effectively saying, at the point that they're prompted with that screen, they accept that they're happy for their identity details to be shared from Google to Salesforce. Okay, so I've redirected to the authorization endpoint. So she, it's over with you again now. They they logged in at Google. You said on my end, I don't need to do anything anymore. You know,
[32:29] yeah. But I can assume it's a similar theme. As the sample process on on my end on the Google end is that I check the user's credential. Once everything's correct, I still prepare the response content. Yes, that's right. Yeah, so. So here we're following an an authorization code auth flow. Effectively, that there is there is a an implicit grant version of this, but but the more secure one's the authorization one. And so, so as part of this flow, so so once you've kind of checked that the user is logged in and that they have previously consented to to all of the all of the scopes, so the identity token and. And anything else that I've requested as Salesforce, you'll send send me as Salesforce a an authorization code, which. Basically allows you in a moment to to then get details for that user. So so the authorization code corresponds to the user, but it's it's very difficult to misuse that code if it's intercepted because at the moment this is all happening through browser traffic. Okay. So the authorization code is yeah, it's effectively just kind of a pointer that you can use to to find details for that user in in a moment. Okay. This now it sounds a bit different from the sample, and right now we have the authorization code. Yes, yeah, this is one of the mechanisms in OAuth that helps it to to be as secure as it is because we've we kind of got that separation
[33:59] between sort of browser traffic and and back channel communication in the authorization code flow. Okay, so yeah, so ensures that we don't need to send any any sensitive information through the browser. Uh huh. So, so I'm I'm going to receive that at the at the redirect URI and in Salesforce the callback URL, and then I'm going to straight away. So I'm straight away. I'm going to use that authorization code in a a post to your token endpoint at Google. Okay, so that that post is that's going to happen outside of the browser, so it's going to be a sort of a back end call, hopefully very familiar. is in in the context of OAuth, so I'm going to have a client ID and a client secret in there that correspond to the Google token endpoint and. Those again, those would be managed by Salesforce as sort of the its kind of central understanding of how to communicate with Google, and then there's also the authorization code will be included in that. Yeah, so. Over to you again, as Google. So I've sent you an authorization code, and I've I've sent it to your access token endpoint. So I've basically asked you for an access token and potentially an ID token as well here. Okay, let's see if I can get it right on my end. I received an authorization code. Authorization code. Yeah, I will check that to make sure it's valid and it's from the right person sending to me,
[35:29] and then I return. Yeah. So your your response would yeah would include an access token and and an ID token as well. Generally, okay. Then I give you back two other new tokens. Yes. Yeah. Okay. This is kind of where it gets then a little bit sort of up to implementation, but in some circumstances it and it depends how this flows sort of figured. But it it could be that actually we just sort of stop there. So Salesforce at this point has the identity token, which includes you know generally sort of the user's name, email address, you know maybe a URL to their picture, that kind of thing. Okay. So that that would allow Salesforce to sort of correlate that to to an end user. But the the best practice with this flow actually is to is for Salesforce to call what's called a user info endpoint, and Google, which is sort of the the the the stand standardized way of retrieving user details. So the user info endpoint would be called with the access token for for that user, and then would yeah would would return again kind of identity claims for for that user, and that's that that would be sort of a standardized way of getting that that that information about the user. So that that's that's kind of the the recommended version is to have that extra extra call. Okay. And in addition to that, your
[36:59] Salesforce also has the access token of the user. That's right. Yes. Yeah. Yeah. So that and which might be helpful for other things as well. So of course, if you know if there are APIs at Google that Salesforce might need to call on behalf of that user, then there's after at the end of the the Open ID Connect flow, Salesforce has the ability to to do that as well. So. And so, yeah, that can be an advantage of using this flow. But the Salesforce only has as much permission as the user at the the login phase granted you to do right. Scopes are sort of generally quite broad, so yeah, it might be sort of a scope that you know allows me to use your APIs, or a scope that allows me to sort of. Yeah, kind of effectively authenticate sort of to front end pages. Also, they tend to be sort of defined in quite a broad way. But yeah, it depends what we've or what I as Salesforce have requested as scopes and what the user has agreed to as scopes as to what I'm then allowed to do with that with that access token. So now I think we have finished the Open ID login. So now the user can will be redirected to original page he tries to access. Yeah, that's right. So there's there's a there's also then like a a handler class that's run in Salesforce to actually sort of interpret the contents of that identity token and then correlate to the user and that that side of things. So it can
[38:29] be quite simple in some cases, or it can be quite sophisticated if we need to do anything special to figure out from an email address who might that actually correlate to in Salesforce. But but yeah, effectively, let's let's sort of imagine we've found a user. They're then logged in, and yeah, they can be then served that that original URL. The way that's done, I'm not actually 100% sure if this is how Salesforce does it. But I think often that would be done by the URL being stored as a cookie before OpenID Connect interaction happens, so that yeah, in the browser, Salesforce can recognise what that page was and serve the right page. But but you know Lawrence, it triggers my interest here is that why there are these differences between this sample and the Open ID because for sample it's really easy for me to follow, but in Open ID there are two or three steps. Try I can see it's kind of like a separate the role of the the actions. But is that necessary? What kind of security concerns do we have? Yeah, yeah, that's that's right. So, so yeah, Open ID Connect, and certainly in that configuration that I ran through, which is the yeah piggybacking off the authorization code flow. I mean, it does have those those advantages that I mentioned around ensuring that we don't have you know any potentially sort of personally identifiable information, for example, won't be shared in the browser. I mean, that can be the case with a sample based flow, but you kind of have to. You know, potentially you
[39:59] might need to make sure that that that user identifier is you know maybe rather than using an email address, you might want to use something more secure like a a generated identifier something like that. But that that's not concerning quite the same way with with with OpenID Connect. Certainly, if you wanted to send sort of other things about the user, so I mentioned you can we can have sample attributes added by Google that sort of represent other information about the user, and yeah, you can imagine sort of very quickly that could end up having quite a lot of sensitive information in it. There are ways to to mitigate against that as well. So we can we can configure that assertion to be encrypted. So Google could encrypt the assertion, and then in the Salesforce side, we can have the certificate uploaded that can be used to then decrypt the assertion. But it's you know yeah, it's this the sort of an extra steps to doing that. I think the other I mean aside from sort of the specific um yeah kind of pros and cons really. One one of the nice things about Open ID connectors is of course it's all it's all OAuth based. It's all sort of yeah sort of REST calls and JSON and you know technologies that are. Very familiar and and in wide use in mobile applications and and web applications of of all kinds. So whereas the Saml standards is very much this is a Saml Saml specific kind of thing and it uses XML and it's so it's likely
[41:29] if you know if you're building a new application that you know needs to support single sign-on, it's Probable that you'd need to do something very special for Saml, whereas for Open ID Connect, assuming that your application has some REST interaction anyway, then then it's likely you know from a development point of view, yeah, you're working with something very familiar and and possibly already have kind of some of the the mechanisms and infrastructure already established to to to do that and to extend out to to support Open ID Connect flow. Okay, I got it.
[42:07] Is that the corporate side only can use the Saml, or is it also be able to use the Open ID? Yeah, so so yeah, absolutely. Within corporate applications, it is it's possible to use Open Identity Connect as an alternative to Saml, and I believe that's becoming more popular as as an alternative. To be completely honest, I think probably the main reason it's not already more popular is kind of the the inertia behind the use of Saml. So Saml's been around for a long time already. It's kind of generally quite well understood by IT teams. It's often in place already for a number of applications. So I think the the the main reluctance I think is more it's it's more just that it's it's a change than it's necessarily a real yeah that there's a reason not to use Open ID Connect. The one thing I would want to know is that in Salesforce, when we configure Open ID, there are multiple steps of talking with Google. Is there a good way for us to troubleshoot between each step? What token I got? What result I receive? You know. When I set up the open ID, I need to debug it, right? Yeah, it's a really good question. It's and it's actually one of the things that I do think. And there's probably ways of doing this that that I'm not aware of that make this easier. But I personally find it a lot easier to debug. Saml interactions, but simply because it's all in the browser, so everything's happening in one environment.
[43:38] There's and there's a lot of really helpful tools out there. So there's a sort of a Saml tracer tool that allows you to very sort of easily extract. And you can kind of have as a browser extension, you have running as you're carrying out a SSO interaction, and it'll pull out the SAML request for you. It'll pull out the SAML assertion for you. So it makes makes it very easy to to see what's going on at the browser level. Because with OpenID Connect, it's typically sort of split between browser interactions and back channel interactions. That can be harder to do. Of course, inspecting the browser traffic through Something like sort of Chrome, sort of Dev Tools works works quite well. You can sort of see what's what's going on to some extent with that, and also you know sort of simulating some of the requests with with Postman or or some. Something like that can can be quite helpful for for debugging. You know, making sure that you're getting the authorization code back okay. That side of things, and similarly, you know, simulating those back channel interactions between Salesforce and Google. But yeah, there's there's not an a especially easy way that I'm aware of that you can kind of monitor the the actual sort of interactions between Salesforce and Google in in that kind of back channel. I think it is. It is probably a little bit more tricky to yeah to kind of monitor that that whole sort of end-to-end flow. I guess this is also one of the reasons the corporate side is still in Samoa. Yeah, possibly. Yeah, yeah. Okay, so thanks a lot to Lawrence. It's really great to have you on the show, and I really love
[45:08] the examples you gave us. It helps a lot in the audio, you know, medium to to explain things and share your knowledge. Pleasure. Thank you, Xi. Yeah, great, great to be on. Thanks, thanks a lot. Talk to you next time. Bye bye. Thanks. Bye bye.
