Customer SSO

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

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 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 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

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 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 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 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.

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 good for security and 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 on-premise or in the cloud.

Contact us now to discuss how you can get started!