Having trouble comprehending how SAML works “under the hood”. Can someone this for me?
In: 2
~~SAML is a configuration language.~~
~~It’s basically a way to represent structured data (numbers, strings, booleans, lists and maps) in a human readable way.~~
~~What it does depends how it is interpreted by the software reading the configuration file.~~
Let’s try that again
high level view, SAML is a defined markup language that contains your credential provided to you by an authentication provider along with any additional claims (like email address, groups, other claims provided by authentication sites that federate with the one your relying party uses)
The general flow goes:
– you go to a website. The website says: if you don’t have a SAML token, log in here: (authentication url)
– your browser goes to that site, asks you to log in.
– you log in (it might send you to other sites to log in or request multifactor authentication)
– on success, it gives you a SAML token and redirects you back to the original website
– you provide the token to the website and are now authorized.
The token is encrypted with a key that is shared between provider and server and signed by the provider.
Ok, sorry about the first comment, too many ETLA. let’s try again.
SAML is a Single Sign On protocol. It allows to securely use a single account to sign in multiple services. If you see the “Login with Facebook”/”Login with Google”/”Login with Apple” buttons, that’s basically what it lets you do (caveat at the bottom). That involves three entities:
The user (you), the Relying Party (whatever website you want to login into), and the Service Provider (the service actually responsible for your account, e.g., FB, Google, Apple).
When you click on the Login with Google button, the website will send you to Google with a special message that does three things:
– ask Google to authenticate the user
– let Google know where to send the user (and authentication information) once they are authenticated
– proves the website is who they say they are
Google will make sure they know the website and the address it wants them to send info to is legit and will ask the user to authenticate. It could be as simple as “Yes, I want to login there, let me go through” or as complex as asking for username, password, 2FA, verifying it’s a legitimate login, whatever security Google actually enforces on your account.
Once that’s done, Google sends the user back with another special message that does 3 things:
– identifies the user (“yes, I can confirm this is the user foobar from gmail.com”)
– proves the message comes from Google
– Adds a few information about the authentication (“I don’t want you tu use this info after 5h because I need to make sure the user is still there and their account hasn’t been locked and stuff).
Note that this doesn’t include your password or any actual credentials, just Google saying “Yes I know this person, their name is FooBar”).
With that information in hands, the website basically just trusts Google and will login the user without requiring additional passwords and stuff.
The benefits are:
– the website doesn’t have to deal with storing password, dealing with 2FA or account recovery.
– the user doesn’t have yet another password to remember and 2FA to setup
– if the user thinks their credentials have been compromised, they can just change their password in one spot
– all the accounts are basically secured by Google fraudulent login detection and protection
Of course this has drawbacks as well:
– if your Google account is compromised, you’re SOL. But that’s usually true even without SAML since password/account recovery is usually email based.
– if you loose access to your Google account, well, that’s all of it.
– You basically have to advertise and rely on the fact you’re using Google for your emails. If you want to change email provider, you’ll have to either find another provider that is as widely trusted or create passwords for all these accounts.
Caveat from the top: SAML is just one of the protocols for SSO and a pretty old one at that. Modern websites and these shiny “Login with” buttons will probably rely on OpenID Connect which offers a bit more security and flexibility, but the differences really are details. When implemented properly SAML can be quite safe. The end result is basically the same.
Latest Answers