Administrative management of SSO
Differentiating SSO behavior for applications and clients
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.
Learn the basics of SSO
For a general overview of SSO with OpenID Connect, see Web Client SSO with OpenID Connect
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
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.
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 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
To exclude a client from SSO the following can be done:
- Use a different authenticator for that client
force-authnon that client
Force Re-Authentication (
force-authn) can be configured on a client. This is the same as if the client always would send the
prompt=login request parameter.
For more information, see the Curity Developer Portal on SSO.