Configuring Client-Based Session Security
AM can issue CTS-based sessions, which contain a reference to the real session stored in the CTS store, or client-based sessions, which contain all the information that would be held in the CTS store.
While both types are susceptible to cookie hijacking, client-based sessions are even more vulnerable, since they contain all the information for the session. Therefore, the malicious user could tamper with the session data to their benefit.
When using client-based sessions and client-based authentication sessions, you should configure AM to sign and/or encrypt the JWT containing session information:
AM verifies that the JWT is authentic by validating a signature configured in the Session Service. AM thwarts attackers who might attempt to tamper with the contents of the JWT or its signature, or who might attempt to sign the JWT with an incorrect signature.
Knowledgeable users can easily decode JWTs. Because an AM session or authentication session contains information that might be considered sensitive, encrypting the JWT that contains it protects its contents, ensuring opaqueness.
Encrypting the JWT prevents man-in-the-middle attacks that could log the state of every AM session. Encryption also ensures that end users are unable to access the information in their AM session.
Signing and encryption require certificates and shared secrets. When deploying multiple AM servers in a site, every server must have the same security configuration. Shared secrets and security keys must be identical. If you modify shared secrets or keys, you must update all the servers in the site. For more information about managing certificates for AM, see Configuring Secrets, Certificates, and Keys.
Client-based sessions and authentication sessions share the same encryption and signing configuration for the realm.
Important
To ensure that the client-based session cookie size does not surpass the browser supported size, Web Agents and Java Agents do not support both signing and encrypting the session cookie. For more information, see "Client-Based Session Security and Agents".
The following sections provide detailed steps for configuring client-based session and authentication session cookie security:
Configuring the JWT Signature
Configure a JWT signature to prevent malicious tampering of client-based session and authentication session JWTs.
Perform the following steps to configure the JWT signature:
Navigate to Configure > Global Services > Session > Client-based Sessions.
From the Signing Algorithm Type drop-down menu, select a suitable algorithm for your environment.
The default value is
RS256.Note
You should disable signing the JWT if you plan to encrypt the JWT with the Direct AES Encryption algorithm. To disable JWT signing, perform the following steps:
Navigate to Deployment > Servers > Server Name > Advanced.
Set the
org.forgerock.openam.session.stateless.signing.allownoneproperty totrue.Save your changes.
Navigate to Configure > Global Services > Session > Client-based Sessions.
From the Signing Algorithm Type drop-down list, select
NONE.Save your changes.
If you specified an HMAC signing algorithm, change the value in the Signing HMAC Shared Secret field if you do not want to use the generated default value.
If you specified the RS256 signing algorithm, specify a value in the Encryption RSA Certificate Alias field to use for signing the JWT signature.
Save your changes.
For detailed information about Session Service configuration attributes, see the entries for "Session".
Configuring JWT Encryption
Configure JWT encryption to prevent man-in-the-middle attackers from accessing users' session details, and to prevent end users from examining the content in the JWT.
Perform the following steps to encrypt the JWT:
Navigate to Configure > Global Services > Session > Client-based Sessions.
From the Encryption Algorithm drop-down list, select a suitable algorithm.
If you selected
RSAin the previous step, you can select one of three padding options using the advanced propertyorg.forgerock.openam.session.stateless.rsa.padding:• RSA1_5. RSA with PKCS#1 v1.5 padding. • RSA-OAEP. RSA with OAEP and SHA-1. • RSA-OAEP-256. RSA with OAEP padding and SHA-256. In the AM console, select Configure > Server Defaults > Advanced.
In the Add a Value field, enter:
org.forgerock.openam.session.stateless.rsa.padding.In the corresponding Add a Value field, enter one of the padding options. For example,
RSA-OAEP. The default isRSA-OAEP-256.Click the plus sign ("+"), and then click Save Changes.
For the underlying content encryption method, select one of the following encryption methods supported in AM:
• A128CBC-HS256. AES 128-bit in CBC mode with HMAC-SHA-256-128 hash (HS256 truncated to 128 bits) • A192CBC-HS384. AES 192-bit in CBC mode with HMAC-SHA-384-192 hash (HS384 truncated to 192 bits) • A256CBC-HS512. AES 256-bit in CBC mode with HMAC-SHA-512-256 hash (HS512 truncated to 256 bits) • A128GCM. AES 128-bit in GCM mode • A192GCM. AES 192-bit in GCM mode • A256GCM. AES 256-bit in GCM mode In the AM console, select Configure > Server Defaults > Advanced.
In the Add a Value field, enter:
org.forgerock.openam.session.stateless.encryption.method.In the corresponding Add a Value field, enter one of the padding options. For example,
A128CBC-HS512. The default isA128CBC-HS256.Click the plus sign ("+"), and then click Save Changes.
In the Encryption RSA Certificate Alias field, enter an alias value to use for encrypting the JWT signature.
AM retrieves the certificate from the keystore specified by the
com.sun.identity.saml.xmlsig.keystoreproperty.If you selected AES KeyWrapping or Direct AES Encryption, enter the key in the Encryption Symmetric AES Key field.
This should be a base64-encoded random key. For direct encryption with AES-GCM or for AES-KeyWrap with any content encryption method, this should be 128, 192 or 256 bits.
For direct encryption with AES-CBC-HMAC it should be double those sizes (one half for the AES key, the other half for the HMAC key).
Save your changes.
Ensure that the JWT signature configuration is identical on every AM server in your AM site.
(Optional) To compress the session state, select
Deflate Compressionfrom the Compression Algorithm drop-down list.Warning
When set to
Deflate compression, this option may lead to a possible vulnerability with session state information leakage. Because the session token compression depends on the data in the session, an attacker can vary one part of the session (for example, the username or some other property) and then deduce some secret parts of the session state by examining how the session compresses. You should evaluate this threat depending on your use cases before enabling compression and encryption together.By default, AM rejects compressed session JWTs that expand to a size larger than 32 KiB (32768 bytes). For more information, see "Controlling the Maximum Size of Compressed JWTs".
For detailed information about Session Service configuration attributes, see the entries for "Session".
Client-Based Session Security and Agents
To ensure that the client-based session cookie size does not surpass the browser supported size, Web Agents and Java Agents do not support both signing and encrypting the session cookie. To configure agents with client-based sessions, implement one of the following configurations:
Configure signing and compression:
Enable HS256 signing for the client-based session cookie. For more information, see "To Configure the JWT Signature".
Enable compression by navigating to Configure > Global Services > Session > Client-based Sessions and selecting
Deflate Compressionfrom the Compression Algorithm drop-down.
Configure encryption and compression:
Set the
org.forgerock.openam.session.stateless.signing.allownoneadvanced server property totrueon every AM instance in the site.Disable signing for the client-based session cookie by navigating to Configure > Global Services > Session > Client-based Sessions and selecting
NONEfrom the Signing Algorithm Type drop-down.Enable Direct AES Encryption. For more information, see "To Configure JWT Encryption".
Enable compression by navigating to Configure > Global Services > Session > Client-based Sessions and selecting
Deflate Compressionfrom the Compression Algorithm drop-down.
Failure to set up client-based sessions correctly may cause unexpected errors when accessing a protected resource, such as blank pages and redirection loops.
Client-based sessions do not support restricted tokens. Therefore, Web Agents and Java Agents configured in a realm configured for client-based sessions are not protected against cookie hijacking. ForgeRock recommends using web or Java agents with CTS-based sessions.