SSO (Single Sign-On) is an authorisation capability of Identity & Access Management (IAM) that works wonderfully, but includes much more than meets the eye. Let me share some light on the technology…

SSO is the technology that allows a customer or partner (or any user) to browse from one online site or application to another without the need to manually re-authenticate when you enter the second service. It provides a seamless experience for your users when engaging with your applications and services. Instead of needing to remember many different sets of credentials for each application or service, users simply login once and access all your services and applications.

There are a few underlying topics to help you understand the internal workings of SSO.

Authentication and the Level of Assurance (LoA)

Everything starts with the first access. For the sake of simplicity let’s assume you have already registered with 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 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 SSO to the second application.

SSO 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 written 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 challenging.

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 Identity Provider maintains.

Another benefit of using a centralised 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 Identity Provider 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.

Single Sign-On Protocol Conversion

We rarely see a completely harmonised 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 (Security Assertion Markup Language) and WS-Federation are the old members in the Web SSO protocol club. The new entrants are OAuth, OpenID Connect and Mobile Connect.

If you need to compare the protocols to determine which one(s) are best for your business download our free white paper on authorisation protocol comparison

When two systems that talk in a different language, you need an interpreter. The component that can translate between different protocols (languages) between the applications will be the Identity Provider (see What is an IdP). The IdP takes care of the protocol conversion and allows smooth transition from one application platform to another.

SSO 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 for your Customers

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 extended out of the internal corporate world to embrace customers, partners and other stakeholders. If you can offer customers and partners one identity for simplified login to all digital services and applications, you significantly reduce the friction of engaging with your (often multiple) systems.

It allows you to improve your security posture by reducing the amount of identity credentials you expect your users to manage and instead, consolidate identities with a single identity and one set of well protected credentials for all your applications.

If you can allow your B2B customers to Single Sign-On to your services from their own corporate network and your competition still requires the use of separate authentication, you have gained a competitive edge.

If you can reduce the credentials customers need to remember, there will be less impact on your support help desks – saving you admin costs.

With less password fatigue, users will expose passwords less. That’s a much better security posture against unauthorised access risk.

All these benefits impact the bottom line, and improve customer satisfaction and loyalty.

The technology might sound complex, and yes it is. The good news is that Ubisecure has been pioneering in customer SSO for many years. Our Identity Platform allows you to deploy a leading authentication, SSO and Customer Identity and Access Management (CIAM) solution in a very short time – either in the cloud or on-premise software.

To help companies get started with SSO, we have recently launched an IDaaS (Identity-as-a-Service) solution that makes it faster and easier than ever to embed SSO into your applications. IDaaS, or SaaS delivered IAM, dramatically cuts down the time to value with this core IAM functionality and provides you with a better security posture against breaches.

If you have questions or have an SSO project coming up, Contact us now to discuss how you can get started!

Free IDaaS Trial

To experiment with SaaS IAM, including SSO-as-a-Service, Ubisecure offers a free IDaaS trial.