SSO Cookie

The encryption key is a string whose length is defined by the encryption key size setting.

The signing key is a string whose length is defined by the signing key size setting.

A regular expression pattern that indicates the set of allowed IP addresses, when #isPinToSession() is configured. In the event that there is a mismatch between the cookie IP address and the current request-provided IP address (i.e. network switches, VPN, etc), the cookie can still be considered valid if the new IP address matches the pattern specified here.

Decide if cookie paths should be automatically configured based on the application context path, when the cookie path is not configured.

The signing/encryption algorithm to use.

Whether crypto operations are enabled.

Whether crypto encryption operations are enabled.

The encryption key size.

Whether crypto signing operations are enabled.

The signing key size.

Cookie domain. Specifies the domain within which this cookie should be presented. The form of the domain name is specified by RFC 2965. A domain name begins with a dot (.foo.com) and means that the cookie is visible to servers in a specified Domain Name System (DNS) zone (for example, www.foo.com, but not a.b.foo.com). By default, cookies are only returned to the server that sent them.

When set to true and assuming #isPinToSession() is also true, client sessions (using the client IP address) are geo-located using a geolocation service when/if configured. The resulting session is either pinned to the client geolocation, or the default client address.

true if this cookie contains the HttpOnly attribute. This means that the cookie should not be accessible to scripting engines, like javascript.

The maximum age of the cookie, specified in seconds. By default, -1 indicating the cookie will persist until browser shutdown. A positive value indicates that the cookie will expire after that many seconds have passed. Note that the value is the maximum age when the cookie will expire, not the cookie's current age. A negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits. A zero value causes the cookie to be deleted.

Cookie name. Constructs a cookie with a specified name and value. The name must conform to RFC 2965. That means it can contain only ASCII alphanumeric characters and cannot contain commas, semicolons, or white space or begin with a $ character. The cookie's name cannot be changed after creation. By default, cookies are created according to the RFC 2965 cookie specification. Cookie names are automatically calculated assigned by CAS at runtime, and there is usually no need to customize the name or assign it a different value unless a special use case warrants the change.

Cookie path. Specifies a path for the cookie to which the client should return the cookie. The cookie is visible to all the pages in the directory you specify, and all the pages in that directory's subdirectories. A cookie's path must include the servlet that set the cookie, for example, /catalog, which makes the cookie visible to all directories on the server under /catalog. Consult RFC 2965 (available on the Internet) for more information on setting path names for cookies.

When generating cookie values, determine whether the value should be compounded and signed with the properties of the current session, such as IP address, user-agent, etc.

Turning off session pinning is not exactly ideal. This is a barrier to prevent cookie replay attacks. A cookie that was created with an IP given a certain location cannot be replayed back in a different browser with a different IP from a different location.

There may however be legitimate reasons to turn it off and relax this after careful reviews, if you intend to support a type of user who intends to switch their IP quite frequently. A classic example is the type of user that is on VPN at the time of login, but decides to resume their work a few hours later off VPN or at a different location.

If remember-me is enabled, specifies the maximum age of the cookie.

If a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of settings SameSite=Lax or SameSite=Strict or SameSite=None to prevent external access.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute is used so cross-site cookies can only be accessed over HTTPS connections.

True if sending this cookie should be restricted to a secure protocol, or false if the it can be sent using any protocol.

Principal attribute names that indicates the destination email address for this message. The attributes must already be resolved and available to the CAS principal. When multiple attributes are specified, each attribute is then examined against the available CAS principal to locate the email address value, which may result in multiple emails being sent.

Email from address.

Email subject line.

The subject can either be defined verbatim, or it may point to a message key in the language bundle using the syntax #{subject-language-key}. This key should point to a valid message defined in the appropriate language bundle that is then picked up via the active locale. In case where the language code cannot resolve the real subject, a default subject value would be used.

Principal attribute names that indicates the destination phone number for this SMS message. The attribute must already be resolved and available to the CAS principal.

The from address for the message.

The body of the SMS message.

Flag that indicates whether to create SSO session on re-newed authentication event.

Email BCC address, if any.

Email CC address, if any.

Indicate whether the message body should be evaluated as HTML text. The application of this setting depends on the email provider implementation and may not be fully supported everywhere. This is typically relevant for the default org.springframework.mail.javamail.JavaMailSender.

Set the priority (X-Priority header) of the message. Values: 1 (Highest), 2 (High), 3 (Normal), 4 (Low), 5 (Lowest). The application of this setting depends on the email provider implementation and may not be fully supported everywhere. This is typically relevant for the default org.springframework.mail.javamail.JavaMailSender.

Email Reply-To address, if any.

Email message body. Could be plain text or a reference to an external file that would serve as a template.

If specified as a path to an external file with an extension .gtemplate, then the email message body would be processed using the Groovy template engine. The template engine uses JSP style <% %> script and <%= %> expression syntax or GString style expressions. The variable out is bound to the writer that the template is being written to.

If using plain text, the contents are processed for string substitution candidates using named variables. For example, you may refer to an expected url variable in the email text via ${url}, or use ${token} to locate the token variable. In certain cases, additional parameters are passed to the email body processor that might include authentication and/or principal attributes, the available locale, client http information, etc.

Set whether to validate all addresses which get passed to this helper. The application of this setting depends on the email provider implementation and may not be fully supported everywhere. This is typically relevant for the default org.springframework.mail.javamail.JavaMailSender.

Indicates whether CAS proxy authentication/tickets are supported by this server implementation.

Indicates whether this server implementation should globally support CAS protocol authentication requests that are tagged with "renew=true".

Attribute name that represents a Unix epoch value in seconds. This timestamp signifies the demarcation point such that any authentication attempts that were created prior to that time are treated as revoked and SSO will be ignored. Calculations are based on the UTC timezone. The attribute is only read and never modified/updated by CAS.

Flag that indicates whether to allow SSO session with a missing target service.

By default, CAS will present a generic success page if the initial authentication request does not identify the target application. In some cases, the ability to login to CAS without logging in to a particular service may be considered a misfeature because in practice, too few users and institutions are prepared to understand, brand, and support what is at best a fringe use case of logging in to CAS for the sake of establishing an SSO session without logging in to any CAS-reliant service.

A regular expression pattern that represents an application which must have established a session with CAS already before access to other applications can be allowed by CAS. This is the initial mandatory/required application with which the user must start before going anywhere else. Services that establish a session with CAS typically do so by receiving a service ticket from CAS.

Indicate whether single sign-on should be turned on and supported globally for the server.