IBM Security Verify

 View Only
Expand all | Collapse all

Federation Cookbook and create-unauth-sessions

  • 1.  Federation Cookbook and create-unauth-sessions

    IBM Champion
    Posted Tue November 12, 2019 02:32 PM

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


  • 2.  RE: Federation Cookbook and create-unauth-sessions

    Posted Wed November 13, 2019 05:23 AM
    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


  • 3.  RE: Federation Cookbook and create-unauth-sessions

    Posted Thu November 14, 2019 09:44 AM
    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


  • 4.  RE: Federation Cookbook and create-unauth-sessions

    Posted Fri November 15, 2019 05:45 AM
    Hi Chris,

    I guess this should work, so I suggest you verify the below:
    - On the EAI junction: verify if the session_index is sent along, and its value.
    - On the EAI: how is the credential built? I'm not sure the session_index will be automatically part of the credential. Check what the EAI puts in the credential: is it the same as received through the junction?

    Kind regards, Peter.

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

    Original Message


  • 5.  RE: Federation Cookbook and create-unauth-sessions

    Posted Fri November 15, 2019 09:15 AM
    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


  • 6.  RE: Federation Cookbook and create-unauth-sessions

    Posted Tue November 26, 2019 05:13 AM
      |   view attached
    Hi Jon, Peter,

    Sorry for the late reply. I attached the access log of the request, showing that the session_index (last column) changes as soon as I authenticate with the eai. The thing that I noticed, is that the last part of the session_index seems to stay constant after login (-1033-11ea-b06a-00505691684a)
    FYI: The first test were done using 9.0.7.0 and today's test was running on latest 9.0.7.0 IF0001

    Is there any more info/test you need me to give/do?

    Regards,
    Chris

    ------------------------------
    Chris Quaresimin
    ------------------------------

    Original Message


  • 7.  RE: Federation Cookbook and create-unauth-sessions

    Posted Tue November 26, 2019 06:41 AM
    Hi Chris,

    I had a look at your log file and can see the change in session index you describe (once I figured out your file had newest events first ;).

    I can't explain why your session index is changing but I wonder if it is affected by either:
      1) Use of DSC
      2) How you return the credential from your EAI

    Have you tried testing with DSC disabled?
    Which headers are you using to return user identity from EAI?
        - standard user header
        - external user header
        - credential pac

    To get to the bottom of this you might need a support ticket; I'm not sure we're going to get there here.

    Jon.

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

    Original Message


  • 8.  RE: Federation Cookbook and create-unauth-sessions

    Posted Tue November 26, 2019 07:22 AM
    Jon, I tried with DSC disabled and still same behavior.
    The identity is returned via standard user header (eai-user-id-header = am-eai-user-id)
    I'll do more tests when I have some time and maybe open a support ticket then.

    Regards,
    Chris

    ------------------------------
    Chris Quaresimin
    ------------------------------

    Original Message


  • 9.  RE: Federation Cookbook and create-unauth-sessions

    Posted Wed November 27, 2019 02:56 AM
    Hi Chris,

    I saw a "TAM_OP=cert_login" in your logging file. I wonder if the changing session_id has to do with certificate authentication. 
    And more specifically with the "delayed certificate authentication mode". I'm not sure if this is relevant to your situation though. Just trying to give a hint here, so if you're situation is about client certification, then consider to read this section: https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/concept/con_delay_cert_authe_mode.html
    I guess you're in the scenario "User is unauthenticated". That section says: WebSEAL retains the entry in the session cache for the unauthenticated user, but obtains a new SSL ID from GSKit. The old SSL session ID is discarded. When the user successfully authenticates, WebSEAL replaces the old unauthenticated user credentials from the session cache data with the new user credentials.
    Still, that explanation says that the SSL ID changes, it doesn't say the ISAM session_id changes...

    Kind regards, Peter

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

    Original Message


  • 10.  RE: Federation Cookbook and create-unauth-sessions

    Posted Thu November 28, 2019 04:52 AM
    Hi Peter,

    Yes, it seems you found the problem. Although we don't use the prompt_as_needed mechanism in the tested login flow it still seems to influence the behavior. We used this mechanism years ago so accept-client-certs is still configured as "prompt_as_needed". I changed it to "never" and that changed the behavior and the session stays the same.
    Although we don't use it at the moment, our login framework expects the TAM_OP to be cert_login and I fear that changing it now will break some things we don't expect.

    ------------------------------
    Laurent LA Asselborn
    ------------------------------

    Original Message


  • 11.  RE: Federation Cookbook and create-unauth-sessions

    Posted Fri November 15, 2019 02:59 AM
    Edited by Peter Volckaert Fri November 15, 2019 09:21 AM
    Hi, I guess that unauthenticated sessions are required in many (if not all..) federated SSO flows. It's needed to maintain session state information during such flows, like e.g. OAuth flows.  For example our Twitter integration with Infomap uses the session_index to maintain state during the OAuth flow.

    Kind regards, Peter.

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

    Original Message


  • 12.  RE: Federation Cookbook and create-unauth-sessions

    IBM Champion
    Posted Thu April 21, 2022 08:22 AM

    Hi Jon

     

    It just took me 3 years to get the nuance behind your statement: "You don't get any session cookie until you hit a protected object". Yes, you are right (of course), I am not receiving any session PD_x_SESSION_ID cookie in response for unprotected object.

     

    Now my question goes as follow: how are we expecting WebSEAL's pdweb.sescache to behave with regards to the usage of separate buckets for authenticated and unauthenticated sessions (irrespective on how create-unauth-sessions is set) ? For instance, once I configure unauth-max-entries and max-entries to different sets of values, how can I track them separately ?

    I am assuming there is no way to distinguishing stats from both buckets but just asking.

    s t default-webseald-someappliance stats get pdweb.sescache

    hit      : 63

    miss     : 1

    add      : 5

    del      : 2

    inactive : 1

    lifetime : 0

    LRU expired : 0



    ------------------------------
    Sylvain Gilbert
    ------------------------------

    Original Message


  • 13.  RE: Federation Cookbook and create-unauth-sessions

    Posted Thu April 21, 2022 04:46 PM

    Sylvain,

     

    Unfortunately, there is no way to distinguish the statistics between the unauthenticated and authenticated session caches.  The statistics for both caches end up in the same 'bucket'.

     

    Thanks.

     

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

     

     




    Original Message