SAML2 and SSO

SAML2

SAML2 stands for Security Assertion Markup Language and you can fundamentally think of it as an XML payload sent over HTTP that proves an actor is who they say they are. The user identity data within these assertions are in the form of XML attributes such as email, username, etc and are referred to as claims.

A few quick definitions

IdP: Identity Providers. These are the services that manage and store user credentials, such as Amazon Cognito for those of us who have taken or are taking CCP or Azure Active Directory for the Telescope project.

SP: This stands for service provider and is what the actor would like access to, any application or website that you need authorization to access full functionality, to connect to, etc.

RP: Relying Party. This refers to any service that is relying on an IdP for user information.

SSO: Single Sign On, meaning a user can sign in with one set of credentials across several websites so long as they allow the use of the same IdP. There will be seperate tokens and cookies for each of the websites but they are all redirected to and trust the same IdP so the same credentials can be used.

Claims: In the case of the SAML protocol these are XML attributes such as email, username, etc that come from an IdP that claim the user is such and such.

Bindings: I believe these are also called webhooks, these are post routes that are automated so that when an event such as a user signing in to an IdP occurs it then automatically posts pertinent user information back to the SP upon login. The SP then checks that the IdP is trust worthy and if so the claims that have been posted are used to create the user's information that will be stored as a cookie and stored on the browser for a predetermined amount of time so that logging in over and over is not necessary for every page/service that requires authorization.

In the Telescope project according to David's blog the claims posted had profile information in this JSON format. This came back from the Azure Active Directory to the callback Url he defined once a user signed into their Microsoft account.

{
  "issuer": "https://sts.windows.net/...idp-uuid.../",
  "inResponseTo": "_851...",
  "sessionIndex": "_dfa...",
  "nameID": "[email protected]",
  "nameIDFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "http://schemas.microsoft.com/identity/claims/tenantid": "...app-uuid...",
  "http://schemas.microsoft.com/identity/claims/objectidentifier": "...uuid...",
  "http://schemas.microsoft.com/identity/claims/displayname": "Full Name",
  "http://schemas.microsoft.com/identity/claims/identityprovider": "https://sts.windows.net/...app-uuid.../",
  "http://schemas.microsoft.com/claims/authnmethodsreferences": "http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "Firstname",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Lastname",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "[email protected]",
  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "[email protected]",
  "sAMAccountName": "username"
}

Putting them together

Generally the way this auth-tango works is that there is going to be a RP that would like to check an actor's credentials, it is in the actor's interest to provide the RP with verification so they can access the SP and the services they are after. The actor will have identity information stored in an IdP, this could be belonging to the same system in which case they would be verified and let through or it could be from another trusted system that the RP could redirect to and this is where SAML comes into play. If the actor has their identity information stored in another IdP that the RP trusts they can redirect to that and allow for a SAML assertion to be generated and returned that would be proof of the actors identity along with all the claims the system would need to classify their clearance and other select personal information.

For an example you can imagine signing into the Epic Games Launcher to play Fortnite. You could have an Epic Games account and log in straight away or you could not have one and select log-in with Google. Epic Games redirects to a Google log-in form and allows retrieval of your information through Google's IdP which it also trusts, google will pass back a SAML2 assertion with some of your information and you will be allowed to play your games.

In this case...

the Relying Party is Epic's Login system that is gatekeeping you,

the IdP would be Google Sign-in,

the Service Provider is the Launcher that has the games you would like to play,

and there would be a SAML assertion created with the info Epic wants.

For another example closer to home lets discuss Telescope.

Telescope similarly is bound to Azure Active Directory. When you request to sign in it redirects to Microsoft, once you log into Microsoft it is bound to automatically send a post back to Telescope with the user information in the format we have above. This is used to authorize the user and establish a session and cookies so that we don't have to constantly be logging in so long as Telescope trusts us.

This can also be used to illustrate the power of SSO. Lets say you are already signed into Microsoft on your browser, you are looking through your Outlook. Microsoft has already verified who you are through their IdP and they have stored a cookie that establishes the relationship between your browser and their IdP. Everytime you go to sign into a new service that uses Microsoft's accounts Microsoft's IdP (Azure AD) will know from the information on the cookie in your browser who you are and will be able to automatically generate the tokens, claims and cookies needed for you to use the next service.

So lets say once more that you want to access Telescope. You are already logged into Outlook. The cookie on your browser will be used to begin the process of prompting the IdP to send the needed claims through the bindings it has with Telescope, posting the necessary information about you to grant you access to Telescope services.

David has previously written a SAML blog when first getting it working with Telescope and has some code explanation in here as well.