Single Sign-On (SSO) is a concept where the user can access multiple sites or apps, without having to enter its credentials again. It is a consequence of using a single point of trust, such as Curity. All sites that depend on the same authentication from Curity can allow the user to seemlessly sign in to the website.
Fig. 134 Single Sign-On Example
For SSO to work both websites in the example needs to have the same requirements on authentication for SSO to work. So if website 1 requires HTML-Form and website 2 requires Facebook there will be no SSO.
website 1
website 2
Once a user has authenticated, an Authenticated Session (i.e. SSO-session) will be created. This is what later can be reused for the next authentication request.
prompt=login
forceAuthN
The authenticated session can be configured in multiple ways. It can be made to disapear when the user closes its browser, it can be persisted to a database and it can be configured to have individual durations depending on authenticator. This section describes the various options.
The authenticated session is represented by an encrypted Cookie in the browser and if configured, an entry in the session database.
A session cookie is not persisted by the browser, thus it’s removed when the user closes the browser. A persisted cookie is stored by the browser until it expires, so it will remain the next time the user opens the browser.
By default the authenticated sessions are stored in a persisted cookie. To configure the cookie to be a session cookie, set the option sso-cookie-is-session-cookie on the authentication profile. (See configuration reference.)
sso-cookie-is-session-cookie
Important
When using sso-cookie-is-session-cookie all authenticated sessions in the profile are stored session cookies.
Storing the authenticated sessions in the cookie has the advantage of not depending on a backing database. However, there are limitations to cookies on size, which can cause issues if the sessions contain many attributes. For example, when using transformers to add attributes to the session, the size of the cookie may quickly grow beyond the bounds of what browsers allow. If this is a case the admin can configure the session to be persisted in the session database instead, and let the cookie only keep a reference.
This is done by setting persisted-sso-session=true on the authentication profile.
persisted-sso-session=true
Note
Using persisted-sso-session does not affect the sso-cookie-is-session-cookie. It can still be a session cookie if desired.
persisted-sso-session
The authenticated session expires depending on what is configured in the authentication profile. There are two ways to configure the expiration.
If an authenticator has an expiration configured this takes presedence. If no expiration is set on the authenticator the profile’s setting is used when the session is created.
To configure the expiration on the profile set the value sso-expiration-time to the number of seconds desired. By default it’s configured to 3600 seconds. See configuration reference for more information.
sso-expiration-time
Each authenticator is configured by setting the sso-expiration-time on the authenticator. This is not required to be configured. See here for details.
It is also possible to configure an optional sso-inactivity-timeout both on the profile and on each authenticator. When defined, the sso-inactivity-timeout establishes the maximum amount of time a session will remain valid without being used to satisfy an authentication request. That is, a session remains valid if:
sso-inactivity-timeout
Note that the values of sso-inactivity-timeout and of sso-expiration-time used to control a session lifetime are the ones configured when the session was created. Changes to sso-inactivity-timeout or sso-expiration-time will only affect sessions created after the configuration change.
Sometimes the administrator wants to force the user to authenticate using two factors on new machines, but allow the user to only enter username password if it’s already authenticated with the second factor on that machine.
With the following setup it’s easy to achieve:
Now, the user will have to re-authenticate with two factors in the same browser every 30 days, but will have to enter credentials on most logins.
The client or service provider can sometimes decide that it does not want SSO. It’s possible to override SSO and force Curity to re-authenticate the user even if there is an existing SSO session..
There are two ways of doing this
The client can pass the query parameter auth_fresh when requesting authentication (or max_age via the authorize endpoint for OpenID Connect). The parameter takes a value in seconds that sets a requirement for how recent the user needs to have authenticated.
auth_fresh
max_age
authorize
Example: auth_fresh=300 means that the client requires the user to have authenticated the last 5 minutes. If no such session is found the user is prompted to login again.
auth_fresh=300
The client can also request that Curity forces the user to login again. If the parameter forceAuthN is passed (or prompt=login for OpenID Connect on the authorize endpoint) to the authentication service, Curity will ignore all authenticated sessions and force the user to login again. The result will contain an auth_time close to now().
auth_time
now()
When forcing authentication or freshness it’s important that the client verifies the result in the response. The ID Token of OpenID Connect will contain the auth_time parameter that should match the requirement.