What is SAML?

Simply, Security Assertion Markup Language (SAML) is a protocol – a set of rules and guidelines – for authenticating a user to web applications. It does this using the electronic identity and attributes stored in an accepted identity database (SAML defines this as the Identity Provider – IdP) and passing it to the web application (SAML defines this as the Service Provider – SP). More specifically, SAML transactions use Extensible Markup Language (XML) assertions to communicate between the providers. This, in turn, allows a user to use a single sign-on (SSO) to access multiple resources in a domain. Trust is the key here. The IdP and the SP trust each other, and the user is extended that trust.

It gets better! Federation (federated identities and federated systems) allows for users’ identities and attributes to be stored on multiple distinct organizations that trust each other. This allows a user to access resources and services across multiple distinct security domains. The same trust applies but is now extended beyond the boundaries of a single entity. Interoperability is great for user workflow, and benefits security by limiting password fatigue. The user doesn’t need to remember many, or reuse a few, passwords. Admin can more easily track each user across the federated systems. SAML lets these federated apps and organizations communicate and trust one another’s users.

How does SAML work for you?

Meet Alice.

Alice is headed to a conference, she is a visitor, not an employee. She wants access to the conference.

In this story, Alice is the user (the Principal in SAML). The conference hall (the hall) is the front-facing website, the pass table is the Identity Provider, and the conference room (the room) is the main resource or service that Alice wants to access (the Service Provider in SAML).

Alice heads to the hall. The room attendant (website security and authentication) looks for Alice’s credentials, and doesn’t see them. Alice is redirected to the pass table (the IdP). Alice gives her ID (Username and Password + whatever other factor is necessary). Her personal ID could be a picture ID like a license or passport, previously vetted conference pass, a trusted authority (“she’s with me” ie. a trusted broker), or a combination of whatever the pass table accepts to authenticate Alice (that could be PIN#, fingerprint, one-time pass, biometrics, location, authenticator app, or combination). The pass table’s role is to securely determine that Alice is who she says she is and provide proof that it believes this to be true.

If the pass table authenticates Alice – accepts her information – Alice is given a badge. The badge is the pass table’s assertion that Alice is who she says she is. Her badge carries the attributes of Alice – name, email, age, etc. Alice takes the badge back to the room. If the attendant (the website’s security) accepts the assertion, Alice’s attributes are used to determine where Alice is allowed to be. Authenticate then authorize.

A few notes.

The door doesn’t care what ID Alice used at the table, just that she has the badge that asserts she is an authenticated conference user. The pass table doesn’t care what Alice wants to do in the conference just that her ID checks out. Neither one has access to attributes that are unnecessary for their particular role.

The attendant only knows that Alice has a badge, and will check if it’s a badge from a pass table they trust (is it the right colour, location, barcode, etc). The badge (the assertion) can carry attributes of Alice (name, email, age, location, etc.) which can determine where in the conference she can go but that happens after she is authenticated.

The IdP (pass table) and the SP (conference room) in this example are within the same domain – they are both “conference”. In IT reality they can be, too, but they don’t have to be. It is trust that is important here. As long as a trusted IdP (or a trusted broker, like Bread & Butter IO) asserts Alice is authentic the SP will accept it. A website can redirect the user to a trusted broker, which in turn redirects the user to the trusted IdP where the user signs-on using a name + password (+ more factors if required – hint, they should be!), which redirects the assertion back to the broker, who redirects the user and assertion to the website. SAML leverages browser redirects between trusted third parties to authenticate the user.

SAML is a straightforward, standardized protocol to authenticate a user using single sign-on to a domain. The interoperability, a desirable trait in any system, eases both user and system overhead while minimizing exposure at all points in the authentication and authorization chain.

Bread & Butter IO is a trusted broker in the workflow chain. Seamless implementation of SAML protocols is just one
way Bread & Butter can ensure a simple and secure authentication of your users with a wide range of trusted
Identity Providers.