HTTP Session Cookie

Last modified 30 Apr 2025 07:48 +02:00
Table of Contents

MidPoint uses a JSESSIONID cookie for GUI session identification.

JSESSIONID cookie is:

  • Set when user navigates to midPoint.

  • Set to a new value when user logs into midPoint.

  • Deleted when user logs out.

Cookie attributes limit the availability of the session cookie. By default, midPoint attempts to use the strictest valid set of attributes.

MidPoint sets the HTTPOnly and Path session cookie attributes by default. The Secure is added attribute automatically if midPoint is configured to provide an HTTPS port.

If your deployment uses a reverse proxy, you may need to modify or add some attributes on the proxy. See the Reverse Proxy section for details.

HTTPOnly

The HttpOnly attribute helps prevent attacks like session leakage since it disallows client-side scripts, such as JavaScript, to access the cookie.

MidPoint sets the HTTPOnly attribute by default.

Path

The path attribute sets the scope of the cookie and prevents it from being sent to other paths on the same host.

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

Secure

The Secure attribute instructs browsers to only send the cookie if the request is sent over a secure channel, such as HTTPS.

MidPoint sets the Secure cookie attribute only if:

  • MidPoint itself is configured with SSL certificates

  • The connection to the midPoint instance uses HTTPS.

SameSite

MidPoint doesn’t set a default value for the SameSite attribute because its use is deployment-specific and an incorrectly configured SameSite attribute may disrupt integration with certain SSO providers.

The table below lists available values for the attribute and their meaning.

Table 1. The available values for the SameSite attribute
Attribute Description

Strict

The Strict value is the most restrictive option for SameSite, allowing the browser to send the cookie only to the first-party context without top-level navigation. The cookie isn’t sent on requests generated by third-party sites.

Since the browser doesn’t send the cookie on any requests generated from a third-party domain or email, the user is required to log in again even if they already have an authenticated session.

WARNING: This setting may break integration with some SSO providers using protocols like OIDC or SAML.

Lax

The Lax value is less restrictive than Strict. The cookie is sent if the URL matches the midPoint (cookie’s) domain (first-party), even when the link originates from a third-party domain. Most browsers consider this value the default behavior (if SameSite isn’t set) because it offers a better user experience than the Strict value.

None

The None value specifies that the browser can send the cookie in all contexts, including cross-site requests, which was the normal behavior before the implementation of SameSite. If SameSite=None is set, the Secure attribute must also be set; otherwise, modern browsers ignore the SameSite attribute. That means you need to set SameSite=None; Secure to ensure the setting isn’t ignored.

SameSite Attribute Configuration

You can configure the SameSite attribute using the application.yml file in the var directory.

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

Integration with SSO Providers (SAML2)

In the case of a SAML2 SSO authentication setup, we recommend configuring specific session and cookie parameters to ensure correct re-authentication after an SSO logout or session expiration.

MidPoint uses Spring Security defaults for session handling. However, these defaults may not clear invalid sessions or expired cookies properly, especially after SAML2 interactions. To improve stability and reliability, you can customize the session behavior using Spring Boot properties.

Set the following properties in your var/application.yml configuration file
server:
  servlet:
   session:
     cookie:
      timeout: 30m
      max-age: 30m

These settings ensure that:

  • Sessions expire cleanly after 30 minutes.

  • Expired session cookies are removed, avoiding stale session states.

  • MidPoint triggers proper re-authentication after the SSO session expiry.

Reverse Proxy

Some deployments opt to use a reverse proxy to provide HTTPS, while communication between the reverse proxy and midPoint occurs via HTTP.

In these cases, configure the reverse proxy to set the following cookie attributes:

  • Secure: Ensures that cookies aren’t leaked through requests to the HTTP port.

  • SameSite: If you need a different SameSite configuration, set it directly for the midPoint instance or ensure that SameSite is always present.

This configuration is specific to the reverse proxy you use. Consult the documentation for your reverse proxy.

Was this page helpful?
YES NO
Thanks for your feedback