Hi Chris,
I just did some tests here to be sure how this is working. I'm testing on SAM 9.0.7.0 but I don't think this function has changed in a long time.
In my tests I was able to see a consistent tagvalue_session_index in request.log for the following scenarios:
1) Request a protected page, login with built-in forms login, navigate protected pages
2) Request a protected page, complete EAI login, navigate protected pages
3) Request a public page, Request a protected page, login with built-in forms login, navigate protected pages
4) Request a public page, Request a protected page, complete an EAI login, navigate protected pages
5) Request a public page, complete an EAI login, navigate protected pages
I checked headers returned from EAI and they do *not* include session index... so I think maintenance of the session index is handled by WebSEAL and EAI does not have to do anything special.
I can't explain why you're seeing the session index change after login. Can you share a snippet of your request log showing this?
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Thu November 14, 2019 03:37 AM
From: Chris Quaresimin
Subject: Federation Cookbook and create-unauth-sessions
Hi Jon,
We are interested too in being able to correlate the session of an user before and after authentication, so we tried to log the "tagvalue_session_index" ("%{tagvalue_session_index}C" in request-log-format), but we see it changing after authentication (via eai)
("create-unauth-sessions = yes" is present in config)
Regards,
Chris
------------------------------
Chris Quaresimin
Original Message:
Sent: Wed November 13, 2019 05:22 AM
From: Jon Harry
Subject: Federation Cookbook and create-unauth-sessions
Hi Sylvain,
By default, WebSEAL doesn't track unauthenticated sessions. You don't get any session cookie until you hit a protected object and (importantly) there is no way to link the unauthenticated session to a subsequent authenticated session. An example use case is allowing users to add items to a trolley without authenticating but maintain the trolley as they move to being authenticated. Of course, a backend application could set its own cookies to maintain the session but what if you want Access Manager to provide this session?
When you set create-unauth-sessions = yes, WebSEAL will create a session for all incoming connections. You'll get a PD_x_SESSION_ID cookie in response to your first request which maps to a credential in the WebSEAL unauthenticated session cache.
You are correct that the cookie changes during authentication. This is done to prevent cookie-based attacks. So, you can't use the session cookie directly to index the session before and after authentication. HOWEVER, what will stay the same is the session index inside the credential. This is available as "tagvalue_session_index". You can pass it to backend servers in HTTP headers using standard capabilities.
As an aside, this index can also be useful in conjunction with JavaScript (where you have access to the credential) in order to index data in the DistributedCache.
In case you're wondering, the reason to have separate caches for unauthenticated vs authenticated sessions is to ensure that unauthenticated sessions cannot accidentally (or maliciously) overrun authenticated sessions.
To answer your question in context of the federation cookbook, I'm not sure whether unauthenticated session capability is required by the federation cookbook. I suspect it is not.
I hope this helps.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Tue November 12, 2019 02:31 PM
From: Sylvain Gilbert
Subject: Federation Cookbook and create-unauth-sessions
Hi
Please let me know if this topic has been covered elsewhere before.
The Federation Cookbook at bottom of page 57 of 328 indicates to set "create-unauth-sessions = yes".
Is this a nice to have or a mandatory configuration item, and if so, for what specific use case of the cookbook ?
And in a larger perspective (beside federations), what are the pros and cons of unauth session ? My gut feeling tells me it should be enable everywhere for the sole purpose of better session management (unauth and auth session in different pools). But without unauth session enabled, we still get different session cookies before and after a successful authentication occurs.
I would truly appreciate any clarification on this topic.
Thanks
------------------------------
Sylvain Gilbert
------------------------------