Federated SSO, it is all about trust
Posted by Jaco van Rooijen
Ezwim recently implemented SAML based Federated SSO. Most people will hardly notice the short description of this implementation in our release document. The ones that read it will probably just frown and think it is not relevant to them. But it is a very exciting development for me. And I have gained a couple of extra gray hair in the process of implementing it!
Here is a little comparison between trust in the good ol’ days & the way trust works today, just so we have some real world concepts to hang our thoughts on:
When my grandparents still had a farm & grandpa went to the bank, the bank manager would know grandpa & therefore he was allowed to do business. Trust was based on well established knowledge.
Today, I carry an identity card with me in my wallet. When I go to the bank or hospital, they look at my ID card to determine who I am. They don’t trust me because of any knowledge about me; they trust the organization that issued me with the card.
In the computer world, we also have some good ol’ days:
Single Sign-On (SSO)
You have probably used SSO a lot on your office computer without ever thinking about it. You switch on the computer & it asks you for your name & your password. Windows asks some system in the office environment whether you should be allowed to login (it is called the domain server) & gives you access to the computer. Then you open your email and it just works without asking you for another password. That is because some SSO system is in operation that tells your mail who you are. The same happens when you access your office file server and print to the office printer down the hall.
An identity provider is the one you login first (for example, that domain server) and is the one that knows who you are and what you are allowed to do; like grandpa’s bank manager.
A service provider supplies the thing you use next, for example the office file server or printer. This is grandpa’s bank. Or a website on your intranet. Or, and this is the point of this discussion, a website on the internet.
Moving to the modern time:
Security Assertion Markup Language (SAML)
This is a standard XML message format that is used to transfer identity information about a user between an identity provider and a service provider; and this is like my ID card, except that I get a new one for every time I want to do business.
The SAML message contains information about you, called identity claims. It also has some additional security information about the message itself, which helps us determine whether the message really came from your identity provider and whether anybody fiddled with the claims after it was sent. This feature keeps everybody out of the system that pretends to be you, because we don’t have your bank manager around to ask whether it is really you.
Federated SSO
This adds all of this together. You login to the company network at your office; at your identity provider. Then you browse to our website. Your identity provider forwards your identity in a SAML message to us, the service provider. We look at your ID and give you access to our services, not because we know you per se, but because we trust the identity provider that sent us a copy of your ID.
It is a bit more complex than that though, sorry, but those are the concepts. On a technical level, it works more like this:
- you open our login URL in your browser
- we redirect your browser with the URL of your identity provider
- you login at your own identity provider, or if you are already logged in, you skip this step
- your identity provider redirects your browser back to the URL of us (the service provider) with your identity nicely wrapped up in a secure SAML message.
- we open the SAML message & give you access to our services, based on the identity claims.
SO, why does this matter? Well, if your company implements the identity provider side, Federated SSO will remove the need for you to remember yet another set of login credentials for Ezwim Expense Management by giving you access to our services in a secure and robustly authenticated way, directly from your intranet. For example, Federated Single sign-on allows EEM to be integrated with a client’s Active Directory Federation Services or ADFS (which is the Microsoft solution for Federated Single Sign On).
