A few years back I read maybe the best analogy of single sign-on (SSO) for the web that I’ve seen to date. The analogy was describing the different roles involved in the SSO flow on the web and it went like this. The Identity Provider (IDP) in the SSO relationship is like the DMV that issues you a driver’s license or another identifying document while the Service Provider (SP) / Relying Party (RP) is like the bartender at your local establishment that asks you to prove you are able to buy a drink. If you were to, say, write your date of birth down on a napkin and hand it to him he’s unlikely to trust your evidence because the bartender doesn’t know you or trust you. However, if you provide him with your DMV issued identification he is more likely to trust that you are of age. Why? Because there is an agreement (even if it’s not an explicit agreement) in place between the state agency that issued your ID and the bartender who trusts the DMV more than you.
Single sign-on between web resources have a similar agreement where the Relying Party trusts the Identity Provider. So, when the IDP tells the Relying Party that a user is legitimate and has the ability to access a resource the RP is obliged to give access to the user. In this article I’m going to take this analogy a step further to describe a few of the different types of single sign-on technologies, all of which we use at Cobalt, both for authorization / authentication to our network resources as well as for our customer’s Dynamics 365 portals, content management systems and their other web resources.
To start with, imagine, instead of requesting a drink at the bar you are out for a night of dancing at the club and you’re met at the door by a bouncer who wants some proof that you are allowed to go inside. There are a couple of scenarios here.
- The club has an age restrictions (like the bartender) and you need to prove that you are of age (SAML, ADFS).
- The club has a guest list and only those on the guest list are allowed access (SWT).
- The club is obliged to allow high profile individuals and their entourage in no questions asked (oAuth).
In the first example a similar situation exists as the scenario with the bartender described above but in some cases the age restriction to enter the club may be different than the age restriction on buying a drink once you enter the club. Most establishments will give you a bracelet to wear or stamp your hand as a way of identifying individuals who are legal drinking age. This is similar to the claims that come along with a SAML based SSO implementation.
A user who is requesting access to a particular resource (i.e. an alcoholic beverage) may be authenticated (i.e. have proven that they are old enough to gain access to the club) but still need to prove they have permission to access the resource. SAML based SSO implementations include both an authentication and authorization mechanism where specific claims (e.g. user roles) can be passed in to the relying party which detail the permissions allowed for the resource along with the acknowledgement that they are a valid user.
Now let’s examine the scenario where the club has a guest list. In this scenario, you could walk up to the bouncer and tell him your name and the simple fact that you’ve identified yourself correctly against the list of people who are allowed access will get you access to the club without any need to prove your identity. This situation is similar to an authorization only SSO where logging into the IDP and being redirected to the Relying Party with a token that identifies who you are authenticates you as a valid user and allows you to gain access to the resource on the Relying Party. However, as in the case above you still haven’t proven your old enough to buy a drink at the bar. For this, more information is required by the bartender. Cobalt uses SWT or Simple Web Token SSO in conjunction with our RESTful Authentication / Authorization APIs to achieve this type of SSO handshake. In this case the SWT handshake identifies the user to the Relying Party using a unique identifier for the user while the Authentication / Authorization APIs provide the more detailed information about the user for authorization purposes as well as simple demographics.
Finally, let’s imagine you roll up to the club with Jay-Z and Beyoncé. The bouncer recognizes the power couple and without question let’s them and their entourage into the club. This is similar to the oAuth SSO scenario that has gained popularity with sites like Facebook and LinkedIn being the Identity Provider in the SSO relationship. Although there is no explicit agreement between Facebook and the relying party sites (i.e. Jay-Z and Beyoncé don’t need to prove that their entourage has the credentials to access the club) there is an implicit trust that Facebook or LinkedIn will ensure that only valid users will be authenticated via the SSO process. Once the entourage is in the club they may still need to provide ID to purchase a drink or Jay-Z may vouch for them. In this case the authorization can come from Facebook’s graph API which provides access to user’s information in the same fashion as Cobalt’s Authentication / Authorization APIs provide access to Dynamics 365 data related to users in the system.
All of the technologies we discussed operate in pretty much the same manner, their protocols and payloads may be different, but there is, in each case, an agreement between the IDP and RP that the IDP will provide the authentication mechanism for allowing access to a resource as well as authorization and additional data to allow the Relying Party to make decisions about what specific roles a user has. The flow, in general, is such that the authentication takes place on the IDP’s site and a response is sent via http(s) back to the RP. In some cases the response contains all of the information about the user that the RP requires, while in other scenarios only the authentication information is provided and the additional data comes from APIs. Cobalt supports and has implemented each of these different authentication / authorization models for our clients to provide their users with a seamless web experience. Cobalt’s Dynamics 365 portals can be either the IDP or the RP in this relationship which allows for many different configurations of the SSO flow.