Administrative Management of SSO

Overview

In this article will take a look at some typical use-cases and how you can benefit from a differentiated approach to how the SSO for the clients is handled from the operational perspective.

Different clients - different SSO

There may be situations where you want to provide SSO functionality to only parts of a collection of services, or only to selected applications. Or maybe some clients should have sessions with a shorter lifetime.

When is SSO Applied

In order for SSO to be established, there are a few requirements:

• Sites must share ACR:s (Authenticators)
• SSO session must exist
• SSO session is fresh
• No client prompts

Shared ACRs

In order for SSO to work, the sites must have the same ACR in their requests and configuration. So for example if the user logs in with html-form in the first site, and the second site requires a social login, SSO will not occur.

SSO session must exist

There must exist an authenticated session (SSO session) for SSO to work. This might perhaps sound like pointing out the obvious, but there is a bit more to it, since the SSO session also must match the parameters provided in the client request.

SSO session is fresh

The duration of the session is normally configured in the authentication profile (by authenticator) in Curity, but the client can also specify in the request a desired freshness using the max_age parameter, and thereby implicitly request a new login, if the available SSO session is too old.

No client prompts

The client may prompt for authentication, in which case SSO will not be allowed - the client explicitly asked for the user to login again.

Managing SSO

Given the above requirements for SSO it's possible to manage when it occurs both from a administrator point of view and from a Client developer's point of view.

Administrating for security

Being able to make an administrative decision on how different clients should behave when it comes to SSO is very valuable when you have a range of clients with different use-cases or access needs.

For example, you might want to allow one client to modify data but with a stricter SSO schema, while a different client can only create reports from the data, but can have a more lax SSO implementation.

The Curity Identity Server administrator has the following options to allow for SSO:

• Define the clients that should participate in SSO
• Make sure these share Authenticator settings. I.e. have the same subset of authenticators configured
• Ensure that none of the clients is configured with force-authn set to true.

To exclude a client from SSO the following can be done:

• Use a different authenticator for that client
• Enable force-authn on that client

More information

For more information, see the Curity Product Documentation on SSO.