Single Sign-On Introduction

What is SSO?

This article aims to provide an introduction to Single Sign-On (SSO) with OpenID Connect and discuss some uses for this approach. We will look at how using the Neo-Security Architecture offers significant benefits for your SSO solution and how it allows for increased flexibility and complexity management.

Overview

SSO - Single Sign-On

Single sign-on - SSO - is an authentication process that allows users or clients to log in to one domain and thereby be provided automatic authentication to another domain without further interaction.

Single sign-on allows for continuous use of multiple connected independent or related systems or services. The user identity is maintained across the system and the user is assigned roles and permissions according to the different system settings.

The process ensures that the authenticated session is stored and passed seamlessly between involved services in order to provide access, although the user may be asked to provide consent for new resources in some cases.

Since different services may require different authentication mechanisms, single sign-on also ensures that only systems with the same requirements utilize the authenticated session.

The benefits of SSO

The main benefit of using SSO is that users can move quickly, yet still securely, between applications and services.

With SSO, the user is authenticated for an entire session for all authorized resources. This provides better user experience with fewer authentication prompts.

The applications benefit from this since many applications can act as a single application as the user moves back and forth without noticing that authentication is performed silently.

OpenID Connect and SSO

Single Sign-On is a simple concept in principle, but in itself doesn't provide a protocol, i.e. how an application should interact with the server to achieve SSO.

OpenID Connect can be used to trigger authentication, and thus utilize SSO. The client initiates an OpenID Connect flow, and tells the server what requirements it has on authentication. If these can be met by using SSO, then the OpenID Connect Provider (server) can re-use existing authentication sessions and let the user flow through.

With OpenID Connect, you can bring single sign-on to both mobile and web.

A structured approach to SSO

Typically, in an application you want to protect valuable asssets while still providing easy access to lower value assets.

Most applications contain a few high value assets, while most of the other assets are of a lot less value.

Requiring the user to do a full sign in to the application every time, just because of these high value assets they might not even use, leads to poor user experience and might actually weaken overall security due to the human factor in dealing with that experience.

Therefore it's good to think about what kinds of applications will be present, and what requirements they have on login. It's also good to get a proper understanding about how sessions work, and how they correlate with the authentication sessions (SSO sessions) that an OpenID Connect Provider such as Curity will use.

What are SSO sessions

An SSO session (authenticated session) is a result on the server after a successful authentication. It contains information about:

• How the user authenticated (which authenticator)
• When the user authenticated
• Details about the user that authenticated

When an authentication request arrives at the server, Curity will check if there is an existing SSO session that matches the requirements for the new request.

The following is then checked:

• Is there a SSO session for the requested authenticator
• Is it recent enough (i.e. expired or the client requested a max_age)
• Did the client allow SSO to be used.

The SSO session can only be read by Curity, but it is used to construct the token that will be returned to the client as proof of authentication. In OpenID Connect, that is an ID Token.

Sharing Logins

An important consideration for the SSO solution is to make decisions on which applications should be allowed to share logins.

It is natural to consider the login requirements for the client, and design everything for the expected clients. Often it's possible to categorize clients depending on their authentication needs.

It's important that sharing should always be done from stronger authentication to weaker. If a user logs in with a multi-factor authentication, SSO could be allowed to an application that only requires username password. This is configured on the client in Curity.

Architect for flexibility

One of the main goals for any SSO solution design is to provide flexibility, both in how the SSO session is generated and managed, and in how the solution develops over time. Changes made to the server configuration, for example adding authentication methods or changing policies, will affect how clients interact, and may in cases break the process entirely.

As you can imagine, setups that require intelligence on part of the client will over time develop to difficult requirement management. So, keep that to a minimum, and allow the server to handle the complexity instead.

For example, if you want to be able to allow the client to use the acr_values parameter intelligently, a cleaner solution is to just let the client request according to its needs, and then handle decisions on the server.

Groups

For maximum flexibility, you would want to be able to group different authentication methods together, and let the user, management/security policies, or situation dictate which method to use under which circumstances.

Another useful capability is to be able to chain authentication methods, or - for added complexity and flexibility - entire groups in sequence, perhaps with additional configuration for decision making on the order of authenticators.

This makes it even more important to have authentication as a separate function, instead of having clients managing these things for themselves.

The Group authenticator in Curity is a powerful tool for these scenarios.

Authenticators in the Curity Identity Server

Authentication is performed by Authenticators, which are part of an Authentication Profile. The authenticators define allowed authentication methods for the client, and can include rather complex behavior. Each authenticator has its own set of capabilities that is listed on each authenticator's page.

Obviously multiple Authentication Profiles can be configured, using the same authenticator setup, but with different combinations or processes.

More information

For more information, see the Curity Developer Portal