Thanks Peter for the response!
I read Shane's article and aware WebSEAL session cookie changes when transition from an unauthenticated to an authenticated state. While in my case, info.js is included after WebSEAL authentication. What changes the session cookie is the secondary OTP.
I have studied info.js and managed to set it to domain level using JavaScript, but info.js itself is not the only place set this cookie. As you can see in the next screenshot ACS backend server also set this cookie, WebSEAL rewrite the cookie name
Things goes while with these two ac.uuid cookies since they have the some value
when the user logout, WebSEAL tried to reset the ac.uuid cookie which was set by JavaScript code in info.js, but it doesn't know it is a domain cookie, so the reset doesn't work at all. Also WebSEAL just ignored the one set by ACS backend server.
neither of these two ac.uuid cookie get reset during logout, as you can see the next request still carry those two cookies after logout.
information stored in the last ACS session leaked into the next one when the user login again.
let me know if you have any idea to fix this.
Thanks again.
------------------------------
Frank Wang
------------------------------
Original Message:
Sent: 01-08-2019 03:28 AM
From: Peter Volckaert
Subject: WebSEAL Session Cookie as Attribute Collection Service Session Index
Hi Frank,
Some thoughts about your post:
* The mobile cookbook you are referring to is the rather old (2014?) "ISAM Mobile Demonstration Cookbook" for which I only found a copy on my hard drive. The cookbook does indeed instruct you to change the default ac.uuid to PD_S_SESSION_ID. It's not clear to my why such change was needed/proposed.
* Now, this article from Shane Weeden explains that you better not use PD_S_SESSION_ID as the attribute collector session index since it's value changes when you transition from an unauthenticated to an authenticated state. So I wonder what's wrong with using the cookie generated by info.js itself? What do you mean with "better control"? and what vulnerability does the cookie introduce?
* With regard to (3): the ac.uuid cookie is created in the info.js script which comes with ISAM. So you can change the script to your liking (e.g set a specific expiration date, set a domain, etc). Take a look at the code and it'll be clear.
Kind regards, Peter.
------------------------------
Peter Volckaert
Sales Engineer
IBM Security
Original Message:
Sent: 01-07-2019 04:43 AM
From: Frank Wang
Subject: WebSEAL Session Cookie as Attribute Collection Service Session Index
Hi ISAM Masters,
In order to have better control of the cookie and give the vulnerability scanner one less reason to complain, instead of ac.uuid, we are using WebSEAL Session Cookie as Attribute Collection Service session index as documented in the ISAM Mobile CookBook.
The assumption is the value of the WebSEAL Session Cookie doesn't change from user logon till logout. While recently I noticed this assumption doesn't hold true if there is a secondary OTP authentication by the authentication service.
After the secondary OTP authentication, the session cookie value get changed by one letter as the example below
Before OTP:
1_TlyMhwpe3wTKPnXjh4BFEKWNjP+nCu9uY1HlVsuWBr2p1UafuMA=_AAAAAgA=_T4qG7O725VI7vN23SPj41mhuUKU=
After OTP:
1_TlyMhwpe3wTKPnXjh4BFEKWNjP+nCu9uY1HlVsuWBr2p1UafuMA=_AAAAAwA=_T4qG7O725VI7vN23SPj41mhuUKU=
My questions are:
1. Is there any settings in WebSEAL or AAC which can alter this behavior and make the session cookie constant throughout the session lifetime?
2. If we split the WebSEAL session cookie using `_`, what kind of information is stored in the last two parts?
3. If the answer to the first question is NO, how can I make ac.uuid as a domain cookie instead of a host cookie, and make it to have the same lifetime as WebSEAL session cookie?
Thanks in advance!
Frank