What is Single Sign-On (SSO)?

11 Jan What is Single Sign-On (SSO)?

Single Sign-On is something that works wonderfully, but includes much more than meets the eye. Here, let me try to share some light on the technology…

When you are taking a holiday trip with your family through Europe and you are in a small village somewhere in Italy and your car breaks down, I might suspect that you wouldn’t be happy. Your car is very complex piece of technology and you expect it to just work.

Time to learn how to speak Italian or use extensive hand gestures…

SSO is the (complex piece of) technology that allows you to browse from one online site to another and through some magic you don’t have to re-authenticate when you enter the second service. When it works, you’re a happy camper. There are a few underlying topics to help you understand of what’s under the bonnet of SSO.

Authentication and the Level of Assurance (LoA)

Everything starts with the first access. For the sake of simplicity lets assume you have already registered to the first application. Depending on the level of confidentiality of the information or resources you are trying to access you need to use appropriate authentication for the first application. Authentication can be as simple as determining your IP address and allowing access based on the fact that you are coming from the correct address. On the other end of the spectrum you have authentication methods that use several factors to establish the identity of the user (See “What is multi-factor authentication“). The most typical method of authentication is naturally the much-loved username + password. Unfortunately.

These different authentication methods have different levels of assurance. If you have authenticated with a lower level of assurance in the first application and the second requires higher level of assurance, you need to re-authenticate. But if the levels match or if you have used a higher level in the first application, you can Single Sign-On to the second application.

Authorization Policies

How does an application know what kind of authentication to request? There are two main ways to implement this. The first one is to include this logic into the application. This will increase the complexity of your application as more code, maybe even completely custom code, need to be created and maintained with the application. In environments with multiple applications and separate divisions owning those applications, tracking all the requirements and maintaining them could become a nightmare.

A much better and simpler way is to use an Identity Provider ( See: “What is an identity provider“) that acts as a centralized control point where application specific authorization policies are maintained. Instead of updating and maintaining all your applications, should you change authentication requirements you only need to tweak the authorization policy that the IdP maintains.

Another benefit of using a centralized controlling mechanism is that attributes are part of the authentication event. After you have authenticated the user, some identity attributes become known to the application. If you are using an IdP it can take care of collecting the necessary identity attributes that the application needs and delivering them to the application. This will keep the application environment much simpler, easier to maintain and can help you comply to e.g. The General Data Protection Regulation.

Protocol Conversion

How do I say in Italian “I’m out of gas”?

We rarely see a completely harmonized corporate environment where everything is humming on top of a single technology platform. This is especially visible in companies that have grown through acquisition and mergers. No matter what the reason is, most corporate environments include technologies from different vendors. These different platforms might talk different languages when comes to Single Sign-On. SAML and WS-Federation are the old geezers in the Web SSO protocol club. The new entrants are OAuth, OpenID Connect and Mobile Connect. Most if not all platforms support SAML or WS-Federation and the new ones are quite developer friendly.

When two systems that talk in a different language, you need an interpreter, just like you might need to hunt down Giuseppe the barkeep in the village as he’s the only one speaking passable English. Otherwise you might ask the car mechanic to check the boar (chingiale) instead of the transmission belt (chingia), or ask to get punched in the face instead of a glass in a bar – like I did when I lived in Italy. The component that can translate between different protocols (languages) between the applications will be the IdP. The IdP takes care of the protocol conversion and allows smooth transition from one application platform to another.

Federation

When you Single Sign-On from one corporate application to an application of a completely different corporation you federate to the second application. As federation is a topic for a complete blog entry or a book, here we need to greatly simplify what’s happening under the bonnet. The basic idea is that federation allows users to Single Sign-On between different identity domains (companies). The magic that allows this are the ingredients explained above, the protocols.

Easy for the User, Easy for Your Business

Single Sign-On has traditionally been seen as an internal issue. Enterprise Single Sign-On (ESSO) provides employees easy access to the corporate applications without the need to remember dozens of different passwords or use their smart card reader PIN-pad several times during the day.

Single Sign-On as a concept has breached out of the internal corporate world to embrace customers, partners and other stakeholders. If you can allow your B2B customers to Single Sign-On to your services from their own corporate network and your competitions still requires the use of separate authentication, you have gained a competitive edge. This has the potential of increasing your bottom line, and it will definitely improve customer satisfaction and loyalty. The technology might sound complex, and yes it is. The good news is that we’ve been doing this almost two decades already, so instead of buying a disassembled car or a horse with a cart you can deploy a leading authentication, Web SSO and Customer Identity and Access Management product in a very short time using our Identity Server or Identity Cloud.

Contact us now to get you started!