IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Session token inquirery

    Posted Thu February 07, 2019 11:36 AM
    ​

    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
    ------------------------------


  • 2.  RE: Session token inquirery

    Posted Thu February 07, 2019 01:49 PM
    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
    ------------------------------



  • 3.  RE: Session token inquirery

    Posted Mon August 31, 2020 12:02 PM
    Jon,

    if the PD-ID was captured before the logout, and was passed in moments later after the logout (where pkmslogout and logout-remove-cookie cleared out the cookies from browser), would ISAM still honor the PD-ID cookie?  How do we prevent ISAM to not accept PD-ID anymore that was cleared out by pkmslogout and logout-remove-cookie)?  

    Thanks
    Ravi

    ------------------------------
    Ravindrasinh Parmar
    ------------------------------

    Original Message


  • 4.  RE: Session token inquirery

    Posted Mon August 31, 2020 12:56 PM
    Hello Ravi,

    As far as I know, you cannot prevent the use of PD-ID cookie to recreate a session - that is exactly what it is designed for in the case of a failover to a Reverse Proxy where the session doesn't exist.

    If this behaviour is not acceptable in your environment you will need to disable the failover cookie and either accept that users will have to reauthenticate on failover - or implement the Distributed Session Cache (DSC) instead for failover support.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: Session token inquirery

    Posted Thu October 27, 2022 10:47 AM
    Dear Jon, 

    Kindly note that I'm trying to integrate a web portal with Webseal. I need the "The PD-S-SESSION-ID index cookie" value in order to know if a new webseal session is created to invalidate my web portal session and create new one. Can you please tell me what is the algorithm used to encrypt the 'PD-S-SESSION-ID'? 
    If yes where the keys are configured etc..?

    Best Regards

    ------------------------------
    John Massaad
    ------------------------------

    Original Message


  • 6.  RE: Session token inquirery

    Posted Thu October 27, 2022 11:30 AM

    Hi John,

     As far as I know, by default, the PD-S-SESSION-ID is not encrypted : it's just an abstract string representing a session entry in the session cache of WebSEAL.

     When WebSEAL creates a new session, it issues a "set-cookie" instruction to the browser so you could catch it there.

     But maybe I don't understand your question...

     

    Regards,

    Louis



    ------------------------------
    Louis Beaudry
    Access Management
    Intact Financial Corporation
    ------------------------------

    Original Message


  • 7.  RE: Session token inquirery

    Posted Thu October 27, 2022 04:11 PM

    John,

     

    The PD-S-SESSION-ID cookie is simply an index into the WebSEAL session cache.  What are you actually trying to achieve?

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     




    Original Message


  • 8.  RE: Session token inquirery

    Posted Fri October 28, 2022 01:40 AM
    Edited by Shane Weeden Fri October 28, 2022 01:50 AM

    Put simply, you are using the wrong piece of data to detect session change. Within the user credential you should see a credential attribute tagvalue_session_index. Make sure in your webseal config file:

    [session]
user-session-ids = yes​

    Then on the junction where you want the session index downstreamed:
    pdadmin> object modify /WebSEAL/<your_server>/<your_jct> set attribute HTTP-Tag-Value tagvalue_session_index=session_index

    This should downstream a session index via a session_index header. Uses changes in that to determine when to invalidate your web portal session.


    There is a similar kind of value called tagvalue_user_session_id that you could also use, but the session_index is more concise.
    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 9.  RE: Session token inquirery

    Posted Mon October 31, 2022 08:50 AM
    Thank you so much dear Shane, I've configured the above form pdadmin and I'm able to catch the header: 'session_index' from my  portal. I've only set the flag: "force-tag-value-prefix = no" in addition to your configuration.

    Thank you so much again!

    ------------------------------
    John Massaad
    ------------------------------

    Original Message


Related Content