WebSEAL can host cookies on behalf of browsers and provide
them to backend applications in forwarded requests. These stored cookies
are held in the session cache, or cookie jar, rather than being sent
to the browser.
The WebSEAL cookie jar is instantiated on a per-user session basis.
Cookies not stored in the cookie jar are passed back to the client
for storage.
The cookie jar stores and handles cookies as defined by the following
configuration entries in the [junction] stanza:
- managed-cookies-list
- Contains a comma-separated list of pattern matched cookie names.
Cookies that match the patterns on this list are stored in the cookie
jar. If this list is empty, the cookie jar is effectively disabled.
Note: WebSEAL processes the cookies found in the response
before attempting to add the cookies to the cookie jar. It can sometimes,
based on the junction configuration, prefix the original cookie name
with a junction identifier. This new cookie name will be used when
WebSEAL decides whether to add a cookie to the cookie jar.
- reset-cookies-list
- Determines which cookies to reset when the user session is logged
out. The request received from the client and the response sent back
to the client are both examined for matching cookies. The reset clears
the cookie in the client's cache by returning an empty and expired
cookie in the logout response. This essentially implements a basic
logout for junctioned applications.
Note: WebSEAL processes
the cookies found in the response before deciding which cookies to
reset. It can sometimes, based on the junction configuration, prefix
the original cookie name with a junction identifier. This new cookie
name will be used when WebSEAL decides which cookies to reset.
- share-cookies
- Determines whether or not cookies stored in the cookie jar will
be shared between different junctions.
- validate-backend-domain-cookie
- Domain checking on cookies is only performed if this entry is
set to true.
- allow-backend-domain-cookies
- During domain validation, if this entry is set to false,
the domain is removed from the cookie.
Note: All the preceding configuration items, with the exception of
share-cookies,
can be customized for a particular junction by adding the adjusted
configuration item to a
[junction:{junction_name}] stanza.
where {junction_name} refers to the junction point for
a standard junction (including the leading / character) or the virtual
host label for a virtual host junction.
All response cookies pass through the WebSEAL cookie jar. Cookies
that match the patterns defined in managed-cookies-list are
stored in the cookie jar and removed from the response stream to the
browser. Those that are not stored in the cookie jar are passed back
to the client.
When a request to a junctioned server is sent from the browser
to WebSEAL, the cookie jar is checked to see if the request requires
cookies to be sent to the junctioned server. If the request does require
a cookie from the cookie jar, the cookie is added to the request.
If the cookie has expired, the cookie is removed from the cookie jar
and not sent.
Persistent cookies are not persisted to disk on the WebSEAL machines.
When a user performs a logout, a reset for selected cookies that
are not stored in the cookie jar is sent back in the response. WebSEAL
resets any cookies with names that match the list of patterns in the reset-cookies-list stanza
entry. The reset essentially implements a basic logout for junctioned
applications.
Note: The session management server should be deployed in situations
where the cookie jar is used by multiple replicated WebSEAL servers.
The session management server is the mechanism by which the cookie
jar can be distributed amongst the multiple replicated WebSEAL servers.
In this type of environment, be careful which cookies you place in
the cookie jar. Do not include cookies which get updated on a regular
basis, as this will put additional load on the session management
server which in turn will have performance implications in the environment.