Skip to content

SSO Management

SSO management in didmos2-auth is regulated using the didmos2_sso cookie. This cookie does not have the Expires attribute set on it, that means that it is a browser session cookie. A session finishes when the client shuts down, after which the session cookie is removed.

Many web browsers have a session restore feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed. However, this does not affect the working of didmos2-auth sso management, since it always checks the data inside the cookie to regulate the SSO and SSO Expiry.

The didmos2_sso cookie contains the following information in the form of JSON.

  • sessionId - This is a UUID based session ID. When a session gets expired or a user invokes log out, a new session ID is generated.
  • userId - User ID associated with the SSO session. This userId is used by s targetBackend to check for the existence and the validity of a user during the SSO session.
  • sessionStartTime - The timestamp when the user ia authenticated and a session is initiated.
  • sessionDuration - The duration of the SSO session. The duration can be configured via the sso_duration_in_sec and rememberme_duration_in_sec configurations in the Didmos2SsoCreator microservice. Please note that if a user checks the Remember Me checkbox at the time of the login, the rememberme_duration_in_sec is used instead the sso_duration_in_sec.
  • targetBackend - A didmos2-auth session is bound with and only one target backend. The target backend validates the SSO user during the SSO session. This parameter holds the target backend name.

The content of the cookie is encrypted, and since the cookie is a HttpOnly cookie, therefore its content cannot be manipulated by the client. Furthermore, the cookie has Secure attribute set on it so that the cookie is sent to the server only when a request is made with the https: scheme (except on localhost), and therefore, is more resistant to man-in-the-middle attacks. Saying that, HttpOnly and Secure attributes of this cookie can be omitted from the cookie via the configurations of Didmos2SsoCreator microservice. However, this is not recommended.

The two microservices responsible to regulate the SSO in didmos2-auth are:

  1. Didmos2SsoCreator
  2. Didmos2SsoValidator

Didmos2SsoValidator

This is a Request Microservice and must be configured as the first microservice under the MICRO_SERVICES list in the proxy_conf.yaml. This microservice checks the didmos2_sso cookie. If the cookie exists, it validates the SSO session expiry: Current Time < sessionStartTime + sessionDuration. If the SSO session is not expired, it sets the didmos2_sso_session SATOSA's internal data. This internal data is then used by the backend and discovery related microservices for the validation of SSO user and discovery flows respectively. didmos2_sso_session contains exactly the same fields which are part of the didmos2_sso cookie. If the didmos2_sso does not exist or if the SSO session is expired, this microservice simply continues to the next micro service without setting the didmos2_sso_session SATOSA's internal data.

Didmos2SsoCreator

This is a Response Microservice and must be configured as the last microservice under the MICRO_SERVICES list in the proxy_conf.yaml. If didmos2_sso_session internal data attribute exists, then this microservice simply exits. If didmos2_sso_session does not exit, then it checks if sso_user_id internal attributes is set, if yes, then it creates the didmos2_sso_cookie and set it in the response. The sso_user_id internal attribute is set by one of the backends, for example, sql or ldap. While creating this didmos2_sso_cookie, userId is extracted from the backend related internal attribute: sso_user_id. This backend related internal attribute also contains a boolean flag rememberMe, which is used by this microservice to calculate and set the sessionDuration field in the cookie accordingly. This microservice also sets the targetBackend field in the cookie from the value in sso_target_backend internal attribute, if set. sso_target_backend is set by either SelectionBasedDiscovery or by the DomainBasedDiscovery microservices.