IBM Security Verify

 View Only
Expand all | Collapse all

Anyone implemented a persistent session ?

  • 1.  Anyone implemented a persistent session ?

    IBM Champion
    Posted Fri January 18, 2019 09:07 AM
    Hi everybody,

    We are trying to implement a feature that seemed simple on the paper but that is proving difficult to implement with ISAM :
    - once a user is authenticated, his session should last 24 hours
    - if user completely closes its browser, and comes back later during the 24 hours period he should still be authenticated

    ISAM uses (temporary) session cookies for representing authenticated sessions. These cookies are automatically deleted by the browser when it's closed.
    We haven't found a way to interact with that cookie, and at the moment we haven't found any workaround that would allow us to do what we need.

    Has anyone implemented persistent sessions in any kind of way ?
    Or does anyone have some clues on how we could achieve that with ISAM ?


    Thanks in advance for any information that would help us

    ------------------------------
    André Leruitte
    ------------------------------


  • 2.  RE: Anyone implemented a persistent session ?

    Posted Mon January 21, 2019 01:24 AM
    Andre,

    Unfortunately there is no OOTB mechanism which will allow you to persist the session after the browser has closed.  You could do this by implementing your own SSO protocol in conjunction with an EAI, but this is not trivial.  The development team has an open RFE for this exact capability and this will hopefully be implemented in the next release or so.

    Thanks,

    Scott.

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 3.  RE: Anyone implemented a persistent session ?

    Posted Mon January 21, 2019 01:51 AM
    Hi André,

    With the current functionality of ISAM, I don't think it's possible.
    However, leveraging infomap (or any other EAI for that matter) it should be doable.

    If you activate the DSC, your sessions are stored and managed there and the cookie is just a link to the session. You could store something like encrypt($sessionStartTimestamp:$sessionID) in a persistent cookie with a lifetime of 24h.
    Every time the cookie comes in, infomap/EAI decrypts the content and validates the timestamp is less than 24h ago. If that is the case, the session should still be in DSC and you should be able to continue the session, even after a browser restart.

    Even in the worst case scenario where an attacker may break your encryption and manage to forge the sessionStartTimestamp, the session would have expired on DSC after 24h and therefore it would result in an error situation rather than granting access.

    Depending on how much of your authentication/authorization flow is (already) executed in infomap/EAI, this may or may not be suitable for your current setup.

    This idea is pure theory (I didn't test anything of it), but I thought I'd share it non the less :)
    Hope it helps in any way.

    Kind regards,

    ------------------------------
    Kristof Goossens
    ------------------------------



  • 4.  RE: Anyone implemented a persistent session ?

    Posted Mon January 21, 2019 01:58 AM
    Alternatively - and probabely even easier - You could position a reverse proxy in front of ISAM with the sole purpose of adding an expiration date to the session cookies, turning them into persistent cookies.

    This may require shifting your SSL endpoint to that proxy in stead of ISAM however.

    Kind regards,

    ------------------------------
    Kristof Goossens
    ------------------------------



  • 5.  RE: Anyone implemented a persistent session ?

    Posted Mon January 21, 2019 03:08 AM
    Hello,

    We have built the persistent login for a customer. We use a custom EAI application in combination with the Oauth2 functions within ISAM.  We use Oauth2 to store access tokens.
    1. The EAI will redirect the user to the Oauth endpoint to request a Oauth token
    2. The browser will redirect the browser to the EAI endpoint to process the Oauth token
    3. The Oauth token is used to get an access token within EAI from ISAM
    4. The Access token is stored encrypted in the browser
    5. When the user returns to the infrastructure, the encrypted access token is posted to the EAI 
    6. EAI verifies if the access token is ok
    7. If the access token is ok, the EAI builds the ISAM session for the user
    Using this Oauth functionality requires only a few lines of code within the eai application
    best regards,
    Sander Meyfroot

    ------------------------------
    Sander Meyfroot
    ------------------------------



  • 6.  RE: Anyone implemented a persistent session ?

    IBM Champion
    Posted Mon January 21, 2019 10:09 AM
    Hi everybody,

    Thanks a lot for your ideas and experiences!
    I think there are several answers here that could be real solutions for our problem.

    We are going to start with the solution that will be implemented the faster, the one suggested by Kristof : modifying the expiration date of ISAM session cookies.
    As we have a Datapower in front of all the ISAM proxies, it should be quick to implement without us needing to change anything else.

    I will keep this thread updated with our results for future reference.


    Thank you all for your feedbacks!

    ------------------------------
    André Leruitte
    ------------------------------



  • 7.  RE: Anyone implemented a persistent session ?

    Posted Tue January 22, 2019 07:54 AM
    Hi,

    I recently implemented a "remember me" functionality for a Proof of Concept. The user can then logon with username/password and tick a box (or not...) "keep me logged in". If "keep me logged in" is ticked then - after successful authentication - a persistent cookie is set on the user's browser. So it's a bit different then André's requirement; since it also includes the option of "keep me logged in". Such functionality allows the user _not_ to be remembered on e.g. a kiosk or someone else's laptop.

    The high level design of this authentication mechanism is summarised as follows:
    - Fully written in Javascript using ISAM's Infomap Authentication Mechanism.
    - The Infomap is a kind of "extended" username/password mechanism that also handles - next to password authentication -  the "keep me logged in" flag at login time and handles the creation and validation of the "rememberme" cookie
    - The Infomap calls an OAuth 2.0 endpoint to create the access token. This access token is shipped to the browser using a set-cookie instruction which sets a persistent cookie, the "rememberme" cookie
    - The same Infomap verifies the presence and validity of  incoming cookie "rememberme". Again using OAuth 2.0; "introspect" to be exact.

    I'm planning to clean up my code and further improve this Infomap in the coming weeks.
    I'm also considering to publish my work here or some other public spot.

    Kind regards, Peter

    ------------------------------
    Peter Volckaert
    Sales Engineer
    IBM Security
    ------------------------------



  • 8.  RE: Anyone implemented a persistent session ?

    Posted Tue January 22, 2019 09:00 AM
    Peter,

    You could create a sliding persistent login using the refresh token instead (refresh token is the value of your "rememberme") --> perform a refresh of the bearers every time the "rememberme" is presented to the EAI mechanism, this should get you another access token with which you then perform introspect or userinfo request with and set the new refresh token as "rememberme", thus having reset your persistent login window.

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 9.  RE: Anyone implemented a persistent session ?

    Posted Tue January 22, 2019 09:36 AM
    Hi Dries,

    Agree, but I didn't need a sliding persistent login. Instead the timeout starts whenever a user logs in and has set the "keep me logged in" flag. So I didn't want to reset the timeout every time the user logged in by presenting the "rememberme" cookie.  Hence I used an access token, which was all I needed for my case. In my implementation, there is no need for a short-lived and long-lived token (access and refresh respectively); there's just one token that expires after X hours. As such the access token proves a good choice as it's needed for the introspect call.
    I wonder if such sliding persistent login is something you have seen as a requirement? I would mean that as long as a user accesses the website from time to time, he/she would never have to provide his/her username/password. I don't think most "rememberme" implementations work that way.

    Cheers, Peter.

    ------------------------------
    Peter Volckaert
    Sales Engineer
    IBM Security
    ------------------------------



  • 10.  RE: Anyone implemented a persistent session ?

    Posted Tue January 22, 2019 09:51 AM
    Peter,

    As you mentioned, if you visit the website from time to time, there would be no need for refresh token, I just wanted to catch a case where a "session" idles for longer than the lifetime of the access token (but where the grant is still active), the user would not have to re-enter their credentials, instead it would fall back to refresh tokens as it achieves the same effect, with the sliding window aspect, which is a side-effect of doing it that way.

    I think most rememberme implementations are custom anyway, and this is just another take on it, backed by a standardized protocol/framework.

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 11.  RE: Anyone implemented a persistent session ?

    IBM Champion
    Posted Thu January 24, 2019 02:34 AM
    Hi everyone,

    Some of you mentionned storing an OAuth token in a persistent cookie, and indeed it seems like an nice solution.

    But I can't stop wondering myself about the security implications : how to you manage to mitigate someone stealing the user session (by simply stealing that cookie) ?
    Do you add some kind of additional browser fingerprinting information in the cookie ?

    ------------------------------
    André Leruitte
    ------------------------------



  • 12.  RE: Anyone implemented a persistent session ?

    Posted Thu January 24, 2019 05:33 AM
    Hi André,

    Well, the focus of such long-lived, persistent login should be on user experience and user convenience. It should be the lowest level of authentication: for all more serious things at least a step-up / reauthentication / multi-factor should be used.

    That being said, I did consider security in my implementation, such as:
    - The OAuth token that I store is an opaque token: it does not contain any useful user (or other) information. Just like the PD_S_SESSION_ID it's only a pointer.
    - The persistent cookie which holds the OAuth token has the Secure and HTTPOnly flag, which helps to mitigate quite a few classic attacks like XSS which uses Javascript in the browser.

    Browser fingerprinting is something that could help, but is it worthwhile? At first sight, it's a bit like protecting a 200 euro horse with a 20.000 euro fence, no? Tell me what you think...

    ------------------------------
    Peter Volckaert
    Sales Engineer
    IBM Security
    ------------------------------



  • 13.  RE: Anyone implemented a persistent session ?

    Posted Mon January 22, 2024 12:32 AM

    Just adding a note here for anyone who stumbles on this in the future:
    Some references:

    https://www.ibm.com/docs/en/sva/10.0.7?topic=state-persistent-sessions

    https://community.ibm.com/community/user/security/blogs/shane-weeden1/2020/12/18/ibm-security-verify-access-remember-session-an-adv

    There is now native support for this feature, (has been for a little while). 



    ------------------------------
    Philip Nye
    IBM
    Gold Coast
    ------------------------------



  • 14.  RE: Anyone implemented a persistent session ?

    IBM Champion
    Posted Tue January 23, 2024 02:14 AM

    Hi Philip,

    Thanks for your references! Indeed the native remember-me feature of ISAM offers almost all that is needed for these kind of scenarios.

    On our side, we end up implementing our own remember-me mechanism in our EAI, because we wanted to implemented selfcare functionnalities, where user can see the list of his "trusted browsers" and decide to revoke any of them (or all of them).

    After login:

    Selfcare - Trusted browsers



    ------------------------------
    André Leruitte
    ------------------------------