Hi Louis,
The PD-ID cookie (or failover cookie) contains encrypted session information. It is a "bearer token" meaning that the bearer of the token present it to create a new session. This cookie needs to be wiped from the browser during logout to prevent it being used to create a new session. That's why you see it being specifically reset (set with empty value and very old expiry date).
The PD-S-SESSION-ID is a session index cookie - its only purpose is to index a session in the Reverse Proxy session cache (or DSC if that is being used). When you perform a logout, the session entry in the cache is deleted. Removing the cookie from the browser is unnecessary (from a security point of view) because the cookie doesn't index anything any more.
I think you can have WebSEAL send a reset for the PD-S-SESSION-ID cookie by setting this configuration:
# Remove the WebSEAL session cookie on logout
logout-remove-cookie = yes
A different PD-S-SESSION-ID cookie is generated for unauthenticated sessions, sessions in process of authentication, and authenticated sessions. This prevents attacks where an attacker injects a session cookie for an unauthenticated session and then waits for the session to become authenticated at a later time.
I don't think there's a way to check the session indexed by a PD-S-SESSION-ID cookie, other than present it to a WebSEAL server and see if it allows access.
I hope that helps.
Cheers... Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: 02-07-2019 11:35 AM
From: Louis Beaudry
Subject: Session token inquirery
Louis Beaudry Hi Community,
We are on ISAM 9.0.5
In a situation where I have an authenticated web session with both PD-S-SESSION-ID & PD-ID cookies set on the browser, when a call to pkmslogout is done, is it normal that I receive a "Set-Cookie: PD-ID=; Max-Age=0; Domain=blahblah; Path=/; Expires="Sun, 01-Jan-1995 01:00:00 GMT"; Secure; HttpOnly" for the PD-ID but nothing for the PD-S-SESSION-ID?
If so, I am Assuming that the session represented by the PD-S-SESSION-ID is nevertheless invalidated in ISAM. What would be the simplest most direct way to proove this? Is there a way to question ISAM directly on the status of a session giving it the value of the PD-S-SESSION-ID token?
Trying to access a protected ressource triggers ISAM to refuse the access to the ressource and send back another set-cookie for PD-S-SESSION-ID but with a different value. Am I right in assuming that this new PD-S-SESSION-ID represents a (new) unauthenticated session?
also, if required is there a setting that would force ISAM to send a "Set-Cookie: PD-S-SESSION-ID=; Max-Age=0;" similar to the one for PD-ID when pkmslogout is used? And why is that not the case by default, any issues/draw back to this that I am not seeing?
Many thanks,
Louis
------------------------------
Louis Beaudry
Access Management
Intact Financial Corporation
------------------------------