Back to Basics – Authentication & SSO

I recently started working with a customer on defining the authentication mechanism for a multi-tenant SaaS solution. During the conversation, we discussed about implementing claims based security using Office 365 AD tenant and I could see the befuddlement in his face of developers as if I am speaking Elvish. So I decided to write a series on application security & authorization. This blog is the first in the series.

Let us start with some history. Once upon a time, applications always had its own authentication mechanism.
User enters the username & password and the application validates the user. Simple, eh!

However as the number of enterprise application started growing, the number of usernames to remember also started growing.

Someone said, why don’t we use the corporate username/password for all these applications – In comes “Same Sign On”.

The key here is to re-use the same enterprise user credential in every application. But that means all application username/password has to be synchronized. Well, isn’t it better to keep them in one place and let apps access it?

IT team said “We have org user data in Active Directory already”. Fair enough, applications started interacting with AD.

Problem solved. Right? Nah..not really. Someone said, why do I have to login again if I am already logged in once into my org domain.

Well, that’s what became “Single Sign On” as we hear it today. That’s where Federation was born.

Federation (in security parlance) means someone takes centralized ownership of security and tells you (application) if the user is valid or not. Any application that relies on the federation provider (FP) is called a Relying Party (RP).

The underlying engine that contains the actual user credentials and confirms if the user is the same is called Identity Provider (IdP).

Just to provide an example let us say you are flying from ATL to BOS.

You go to ATL airport and request access to a flight. Now the aircraft carrier could authenticate you and let you into the flight.

But their job is to fly you out, not to validate you. So all aircraft carriers have federated their security to TSA. (FP) You have to provide the TSA with your ticket and your license. Your license was issued to you by DMV. DMV is the “IdP” here.

TSA looks at your license and sees that it is valid and puts some mark on your ticket. This is your “token” (or claim).

You take the token and go to the flight and you get access to the aircraft. You are an end user and the aircraft carrier (RP) relies on TSA to validate your access to the aircraft.

You could use different terminology for relying party, identity provider etc. but you get the flow and security idea right?

That’s all matters.

Now coming back to software development, this security delegation took away the burden on application developers having to develop security within the application. However this introduced a new problem. App developers needed to know how to interact with the federation provider. With that came a host of protocols and mechanisms – WS-Federation, SAML, Open ID, OAuth, OpenID Connect etc..

This confuses a poor application developer whose focus is primarily on the business functionality of the application.

More on tokens & protocols later..