HTTP Session Cookie

Last modified 25 Sep 2024 13:24 +02:00

MidPoint uses JSESSIONID cookie for GUI session identification. JSESSIONID cookie is:

  • set when user navigates to midPoint.

  • new value is set when user is logged into midPoint.

  • deleted when user log outs.

Cookie attributes limits when session cookie is available. MidPoint tries to use strictest valid set out of the box by default.

MidPoint sets following attributes sets HTTPOnly and Path session cookie attributes by default. Secure attribute is added if midPoint is configured to also provide HTTPS port.

If deployment uses reverse proxy, some attributes mey need to be rewritten / added on proxy. See Reverse Proxy section for details.

HTTPOnly attribute

The HttpOnly attribute is used to help prevent attacks such as session leakage, since it does not allow the cookie to be accessed via a client-side script such as JavaScript.

MidPoint sets HTTPOnly attribute by default.

Path attribute

path attribute sets scope of cookie and prevents cookie being sent to other paths on same hosts.

MidPoint by default sets path to /midpoint to limit cookie scope only to midPoint.

Secure attribute

The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS.

MidPoint sets Secure cookie attribute only if midPoint itself is configured with SSL certificates and connection to midPoint instance uses HTTPS.

SameSite attribute

MidPoint does not set a default value for SameSite attribute, since it’s use is deployment specific and incorrectly configured SameSite attribute may break integration with some SSO providers.

Available values for SameSite attribute are:

Strict

The Strict value is the most restrictive usage of SameSite, allowing the browser to send the cookie only to first-party context without top-level navigation. The cookie will not be sent on requests generated by third-party sites.

Since the browser would not send the cookie on any requests generated from a third-party domain or email, the user would be required to sign in again even if they already have an authenticated session.

This setting may break integration with some SSO such as OIDC or SAML.

Lax

The Lax value is less restrictive than Strict. The cookie will be sent if the URL equals to the midPoint (cookie’s) domain (first-party) even if the link is coming from a third-party domain. This value is considered by most browsers the default behavior (if SameSite is not set) since it provides a better user experience than the Strict value.

None

The None value specifies that the browser will send the cookie in all contexts, including cross-site requests (the normal behavior before the implementation of SameSite). If SameSite=None is set, then the Secure attribute must be set, otherwise modern browsers will ignore the SameSite attribute, e.g. SameSite=None; Secure.

Configuring SameSite attribute

SameSite attribute can be configured Using application.yml in var directory.

Example var/application.yml configuraion
server:
  servlet:
   session:
     cookie:
       same-site: Strict

Reverse Proxy

Some deployments opts to use reverse proxy to provide HTTPS and communication between reverse proxy and midPoint is done via HTTP.

In these cases, the reverse proxy should be configured to set cookie attributes:

  • Secure - To ensure that cookies are not leaked by request to HTTP port.

  • SameSite - If there is need to have different SameSite configuration, then for midPoint instance directly or making sure SameSite is always present.

This configuration is specific to the reverse proxy used, please consult documenation of your reverse proxy.

Was this page helpful?
YES NO
Thanks for your feedback