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.  ISAM - Stale session cookie

    Posted Thu May 16, 2019 12:22 PM
    Edited by Magnus Thu May 16, 2019 02:14 PM
    Hello,

    Was wondering if any members in the forum could give an insight why we are having issues with the session cookie PD-H-SESSION-ID as it is being corrupted (stale cookie).

    We are using the DSC with two ISAM appliances and a master-master cluster configuration. We are using the AAC as an authentication mechanism and the dsc consists of two wrp instances in the same replica set. A total of 4 wrp instances, two on each appliance. 

    Endusers are sometimes prompted with a 403 forbidden page and the reason is that the PD-H-SESSION-ID cookie is going stale on their client. Do anyone know or have a working solution to let ISAM force the client to remove or update the PD-H-SESSION-ID cookie? Any insight regarding this issue would be appreciated.

    Best regards
    Magnus

    ------------------------------
    Magnus
    ------------------------------


  • 2.  RE: ISAM - Stale session cookie

    Posted Wed May 22, 2019 09:39 AM

    Hi Magnus,

    What exactly do you mean by "corrupted" ? I assume it's about the cookie that is still at the HTTP client (browser) but is not pointing to a valid ISAM WebSEAL session.
    What if you delete the cookie by sending a set-cookie header in some WebSEAL response page?  Such as a login page, or even the 'forbidden page' itself where you could delete the cookie and then redirect the user to the originally asked resource. 

    In my "custom password" mechanism on Github you can find an example on how to delete the "stayloggedin" cookie in the login page sent by ISAM. See here: login.html. It's using 'template scripting' as follows:
    <%
    // Delete the browser Stay Logged In cookie via server-side template page scripting
    templateContext.response.setHeader("Set-Cookie",templateContext.macros["@DELETE_STAYLOGGEDIN_COOKIE@"]);
    %>
    This eventually results in following set-cookie header in the response:
    Set-Cookie: stayloggedin=; Path=/mga/sps/authsvc; Expires=Thu, 01 Jan 1970 00:00:00 GMT
    This set-cookie will delete the cookie.

    Let me know if this is helpful.

    Cheers, Peter



    ------------------------------
    Peter Volckaert
    Senior Sales Engineer
    Authentication and Access
    IBM Security
    ------------------------------

    Original Message


  • 3.  RE: ISAM - Stale session cookie

    Posted Wed May 22, 2019 12:34 PM
    Edited by Jon Harry Wed May 22, 2019 12:33 PM
    There's also a config option in Reverse Proxy which will perform a Set-Cookie to remove the session cookie on logout:
    logout-remove-cookie = yes

    This only works when the user actively logs out (/pkmslogout) rather than timing out but might be worth a try.

    Jon.

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

    Original Message


  • 4.  RE: ISAM - Stale session cookie

    Posted Wed May 22, 2019 01:14 PM

    Hi Jon

     

    I am curious to know why this setting could not be set by default to "yes" in ISAM.

     

    Why would one want stale session cookie to remain in user's browser after logout?

     

    I know that you already mentioned in some other post that WebSEAL will still consider the session cookie stale if it is presented again, but why not make this clearer by always instructing the browsers to clear stale session cookie?

     

    Maybe for some specific use cases, this is not desirable?

     

    Cheers

     

    Sylvain

     




    Original Message


  • 5.  RE: ISAM - Stale session cookie

    Posted Wed May 22, 2019 01:25 PM
    Hi Sylvain,

    Usually when a seemingly sensible default is not set, it's because the capability was introduced at some point and the default was not to do the new (perhaps better) thing in order to avoid backward-compatibility issues.

    Perhaps if you are using DSC you might not want to clear cookie because it's still potentially in use at another WebSEAL - but maybe with DSC on this option doesn't clear cookie anyway. I'm not sure. 

    Jon.

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

    Original Message


  • 6.  RE: ISAM - Stale session cookie

    Posted Thu May 23, 2019 03:12 AM
    Hello,

    Thanks for all replies.

    We have been able to pinpoint the issue, the issue was related to the session cookie but the issue was not the session cookie itself. We are using the client_identifier in order to fetch the clients source ip from the loadbalancer. As the identifier is added to the session the user will be prompted by a forbidden if the users lease expire and they get an new ip from the dhcp.

    Do anyone know if you can remove the enforcement of the client_identifier so that you can use it but it isnt enforced? We are using this attribute in an access policy to enforce an ip restriction for a federation. Other attributes that we could use is populated by the loadbalancer so the real source IP can only be resolved by using this in the WRP unfortunately.

    Best regards
    Magnus

    ------------------------------
    Magnus
    ------------------------------

    Original Message


  • 7.  RE: ISAM - Stale session cookie

    Posted Thu May 23, 2019 08:46 AM
    Hi Magnus,

    I guess that setting the client_identifier config in the WebSEAL config file to the default of "client-identifier =" (so empty) will instruct WebSEAL not to include such credential attribute and so no verification will be done.

    Next is to get the IP address in the credential. In my testenvironment I see a credential attribute AZN_CRED_NETWORK_ADDRESS_STR[0] which contains the originating IP address.
    Try playing around with use_real_ip_address parameter which is documented here: https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.6/com.ibm.isam.doc/wrp_stza_ref/reference/ref_xacml_use_real_client_ip.html

    (You may have to look at using  the AAC's AuthSvcCredential mapping rule to get things done, but that's only valid when you use the AAC's authentication service.)

    Let me know if you're making progress.

    Kind regards, Peter.



    ------------------------------
    Peter Volckaert
    Senior Sales Engineer
    Authentication and Access
    IBM Security
    ------------------------------

    Original Message


  • 8.  RE: ISAM - Stale session cookie

    Posted Thu May 23, 2019 09:40 AM
    Hello Peter,

    Thanks, when I test it I just get the loadbalancer IP. Do you know if you can insert the xhttpforwardedfor from the loadbalancer that contains the client ip somewhere in the WRP so that will be accessible for the Access policy? 

    Best regards
    Magnus

    ------------------------------
    Magnus
    ------------------------------

    Original Message


  • 9.  RE: ISAM - Stale session cookie

    Posted Thu May 23, 2019 10:14 AM
    Hi Magnus,

    At what point do you want that header to be read: are you using an "access policy" (which is meant for step-up during federation flows) or an AAC "context-based access policy"?
    Depending on this the solution will differ.
    In an "access policy" you can simply read the header using something like:
    var headerValue = request.getHeader(headerName);
    See more here: https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.6/com.ibm.isam.doc/config/concept/access_policies_request_context.html

    When you're in an AAC context then look at "azn-decision-info": see the proxy's config file for examples.



    Kind regards, Peter.



    ------------------------------
    Peter Volckaert
    Senior Sales Engineer
    Authentication and Access
    IBM Security
    ------------------------------

    Original Message


  • 10.  RE: ISAM - Stale session cookie

    Posted Thu May 23, 2019 11:14 AM
    Hello Peter,

    The solution with the access policy worked!

    Thanks for the help.

    Best regards
    Magnus

    ------------------------------
    Magnus
    ------------------------------

    Original Message