Administrative Management of SSO

Overview

Managing Single Sign-On (SSO) clients from an operational standpoint means overseeing the setup, functionality, and security of SSO connections to guarantee smooth and safe user access across different applications.

This article takes a look at some typical use cases and how you can manage them.

Different Clients: Different SSO

SSO implies that the identity server does not request any user interaction as part of authenticating the user because the user has recently enough authenticated at the identity server. Often this behavior is the same regardless of the applications the user interacts with.

There may be situations, though, where you want to provide SSO functionality only to parts of a collection of services or only to selected applications. Alternatively, you may also want some applications to have SSO sessions but with a custom lifetime.

When is SSO Applied?

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

• Sites must be able to use the same authentication methods (identified by the same ACRs)
• SSO session must exist
• SSO session is fresh
• No client prompts

Shared ACRs

SSO only occurs if two applications have the same ACR in their requests and configuration. For example, if the user logs in with a username and password on 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 sound like pointing out the obvious, but there is a bit more to it, since the SSO session must also match the parameters provided in the client request.

SSO Session Should be Fresh Enough

The duration of the session is normally configured in the identity server, but the client can also specify in the request a desired freshness using the max_age parameter. The identity server will reuse the SSO session if it is not older than the requested parameter; otherwise, the user will have to authenticate.

Avoiding SSO

The client may prompt for authentication by sending the prompt=login request parameter, 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 SSO, from an administrator's and client’s point of view.

Administering 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 and can have a more lax SSO implementation.

An administrator could have the following options in an identity server to allow for SSO:

• Define the clients that should participate in SSO
• Make sure clients use the same authentication methods
• Ensure that no authentication method uses the force-authn=true setting

To exclude a client from SSO, an administrator can do the following:

• Use a different authentication method (ACR) for that client.
• Enforce authentication for that client (e.g., by setting force-authn to true).

Client-controlled SSO

OpenID Connect defines request parameters that allow the client to control the SSO behavior for the request. For example, as mentioned before, the prompt=login parameter instructs the identity server to disable SSO and force the user to log in again. You can find more details about how clients can control SSO in How to Prompt for Login during SSO.

Last updated: 2025-02-10

Jacob Ideskog

Identity Specialist and CTO at Curity