If there were no passports…

If there were no passports, how would the World work? We all use lots of Service Providers on a daily basis – shops, banks, utilities. All of them need to know who you are as a consumer. Let’s say you wanted to open a bank account. They would want to record your identity. Therefore, you would need to take proof of your identity… photos, birth certificate, proofs of address etc. That done, how about you want to check in for a flight? Same thing again… photos, birth certificate, proofs of address etc. Maybe open an electricity account? Same again… photos, birth certificate… You would rapidly find that not only was taking all of your information to each Service Provider a tedious task, but many of them would hold similar information and possibly some of them even incorrect or out-dated information.

It would be nice if they could share information between them, but what happens if two Service Providers hold different information, for example different addresses. Which one should be used? And what if one Service Provider needed some information from another, but the other Service Provider was unavailable for some reason? And come to that, what if you didn’t want them to talk to each-other about you? Clearly something better is needed.

What if your identity could be provided by just one authority that everyone trusted? They probably wouldn’t be a Service Provider themselves, but they would store your identity and provide it to you in the form of an identity statement or ‘Token’. So they are not a Service Provider, but they are an Identity Provider. Then you could go to the Service Provider (such as the bank) and give them the ‘Token’ you were issued with, and they would accept that as your authoritative identity. Of course, the Service Provider would need to trust the Identity Provider and know that you were providing a proper ‘Token’ and that you didn’t just print it yourself! To do that, the Identity Provider would mark the ‘Token’ with a certified imprint when they issued it to you, and as the Service Provider knows what certified imprint the Identity Provider uses, they can check it and ensure that the ‘Token’ is proper and valid.

This ‘Token’, of course, is what we know as a passport, and the government will issue you one on request. They are your Identity Provider, and you can take your passport that they issue to a Service Provider who will check it and, if it’s not forged, accept it as proof of who you are and your personal details. Often the additional information on the passport, such as date of birth, are also important to a Service Provider. Try getting a drink in the US if you look like a teenager, and you don’t have your passport on you!

So why on earth am I talking about passports on a technical blog?

Well, I am currently engaged with one of our partners on a project where a Single Sign-On (SSO) solution is needed. When I tried to explain SSO in simple terms to explain how it needed to be approached, I got a bit stuck. The thing is, the SSO documentation you find on the web is way too academic and abstract and it’s hard to talk about it without getting bogged down in acronyms and confusing diagrams.

Therefore, this is my attempt to explain it!

For the most part, the Internet right now is like the world without passports. Every site you use wants to capture a copy of your identity. You end up with your identity all over the place, mostly unsynchronised. Sites don’t trust each-other to share that information, and you probably don’t trust them to either.

This is where SSO comes in. As far as SSO is concerned, every site you use is a Service Provider. All you need is an Identity Provider to issue you an identity token, and a mechanism so that the Service Providers you visit can verify that the identity token you give them is from an Identity Provider that they know and trust. Despite people trying to make it seem complex, SSO really is that simple.

Now we’ve laid the groundwork, let’s get technical for a moment. This description refers primarily to the SAML standard of doing things but the basic theory is valid for SSO in general.

Your identity will be stored by an Identity Provider who, when you log in to their site, will give you a token - part of which may be encrypted. The Identity provider will have a certificate and will use a key from that certificate to sign the Token as well. That certificate is shared with the Service Providers that want it so that the Service Provider can verify both who the Token is from and that it is unchanged.

Once logged in, the way to get that Token to the Service Provider varies depending on what you are trying to do. If you visited the Service Provider site first, they will redirect you to the Identity Provider’s site to login and will then redirect you back to the Service Provider’s site once complete. Behind the scenes, after logging in the Identity Provider will probably have called a service on the Service Provider to POST the Token. That means that the Service Provider can then unwrap the Token, verify it and write an authentication ticket. The redirect can then happen and the user should be logged in.

If you log in at the Identity Provider’s site, then you will need to click a link or something to redirect through to the Service Provider. The same behind the scenes will happen. Sometimes, an Identity Provider will give a Service Provider a ‘vanity URL’ which will automatically redirect to that Service Provider after logging in.

There are all sorts of variations on the theme, for example if you access restricted content, but they all work on the basis of logging in at the Identity Provider before passing over to the Service Provider. Using the analogy, it’s almost like the bank would send you off to get a brand new copy of your passport then come back, then the electricity company would send you off to get a brand new copy of your passport and come back etc. Not very practical in real life but perfectly reasonable in an electronic world!

SSO really is a very elegant way of doing things. Your login credentials only ever remain at the Identity Provider, and the Service Provider only ever needs to listen to requests (called ‘assertions’) and verify them against the certificate obtained from the trusted Identity Provider.

In the next part, I will give some implementation tips + advice on how to get going with EPiServer and SSO. If this post has been helpful or you have some advice to improve it, let me know!