Easy things first — SAML stands for Security Assertion Markup Language. It’s a standard.
So what’s it for; what problems does it solve. It’s all about providing convenience, security and scale for access to the services that business users need to do their job. These services are typically web sites although SAML can be used for any service. Note the business focus for SAML; there are other standards that solve similar problems in the consumer world.
Let’s look at the pre-SAML world.
I want to use a service; the service asks me for a user and password; it looks it up in its database. This is the classic authentication case. The service might be an in-house application (my HR app), a consumer site (LinkedIn, say) or a multi-tenant business service like Salesforce. The problems with this approach are:
- Every time I visit a different service, I have to log in (maybe my browser remembers me; but how secure is that? And what happens if I change my password? etc.)
- The administrator of the service has to maintain a user / password database; a well-known security vulnerability.
- My company admin (I am discussing business use here) has no control over what I can do. If I leave the company, what accounts do I still have access to? The admin is not in the loop at all.
The SAML world looks quite different.
I connect to a system called the IDP (Identity Provider). This system is managed by my admin; this is the only place I need to log in. Now when I want to use a service the IDP issues a token to me, and I present this token to the service. Note I don’t see any of this; it all happens ‘by magic’. Notice how each player’s experience is improved:
- I only have to login to one service. In many cases this login is automatic; the system I use automatically connects me if I am on site or asks me for my AD user and password if I am not. No more passwords to remember – Woo Hoo!
- The corporate admin controls the IDP and so he has a single point of control over what his users are doing
- The service administrators no longer have to worry about maintaining user / password databases
The SAML specification describes the content of the token as well as the ‘by magic’ flow under the hood that enables it to be passed from the IDP to the service.
I am sure you are all asking — how does Service1 know that the token can be trusted? It says “this is firstname.lastname@example.org” but how can we be sure that’s true? The answer is that the corporate admin obtains an X509 certificate and installs it and its private key on the IDP. The admin then passes that certificate to the service (the exact mechanism for doing that varies from service to service, but the essence is the same). When the IDP issues a token, it signs the token using the certificate / private key combination; the service can recognize that this token was signed by a trusted IDP. The signature also assures the service that the token hasn’t been tampered with in transit.
This description glosses over many deeper aspects of using SAML. One of the most common issues is that services still needs to maintain a user database of some kind even though it’s not used for authentication. A service may need to make decisions based on what type of user is connecting to it; for example only some users are allowed to cancel orders in an order processing system. In the classic case there would be data in the user database of the service saying if a user has that right (‘is sales manager’ for example). In the SAML case, this data may well be in the corporate user database. In order to facilitate the transfer of this data, SAML allows arbitrary attributes (sometimes called ‘claims’) to be inserted into a token. The IDP is configured so that it knows what attributes to send to each service; one might receive job title, one might receive a list of group memberships, another will get department code, and so on.
In fact a service can use attributes to achieve Just In Time provisioning of users; the tokens that a service receives contain all the information the service needs (Name, email, address, department, phone numbers, group membership). The service can then keep its database up to date as each token comes in.
User provisioning is a huge subject that deserves its own posting — maybe next time.