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.  Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/22/22 02:36 PM
    Edited by Gabriel Labarrera 07/22/22 03:10 PM
    Hi, I find some problem on a client installation when the user is logged on the SAML IdP(SVA Federation) that is hosted on the same WebSEAL instance and they tray to access some junctions or virtual juntion on the same WebSEAL instance but the user is requested to login again, the same behavior is replicated when the user is already logged in on the junctions or virtual junctions and they tried to login on other application via SAML.

    DSC is configured for the WebSEAL instance and the cookie is set for all the host defined on the DSC like "example.com", the standar junctions are access via "appA.example.com" and the virtual junction via "appB.example.com" and they share the same DSC set "ExampleDSC", the IdP uses the host "appA.example.com" to let the users login via saml.

    I already tried to enable the DSC on the Federation module but seems like the module create its own DSC set.

    ------------------------------
    Gabriel Labarrera
    ------------------------------


  • 2.  RE: Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/24/22 09:23 PM

    Gabriel,

     

    The WebSEAL instances, and the IDP will always use a different DSC set because they represent different sessions (you can't share a session between WebSEAL and the Federation runtime as both contain totally different session data).

     

    However, WebSEAL should be able to share the same session between different virtual host junctions and standard junctions, providing the same session cookie is provided on each request.  If different host names are used to access WebSEAL, then you need to enable the domain cookie within WebSEAL so that the same cookie can be sent to multiple hosts in the same domain.

     

    The first thing which I would try in your environment is to enable browser debugging and examine the cookies which are being sent from the browser to the WebSEAL.  I suspect that the correct session cookie is not being sent to the various virtual host junctions.  It might be worthwhile opening a support case to get the support team to help debug your issue as there are many variables in the configuration which could stop the sessions from being shared correctly.

     

    I hope that this helps.

     

     

     

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

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

     

     

     






  • 3.  RE: Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/25/22 10:14 AM

    The WebSEAL instances, and the IDP will always use a different DSC set because they represent different sessions (you can't share a session between WebSEAL and the Federation runtime as both contain totally different session data).

    So, there will be always a login request when you are already logged in on any junction.

    However, WebSEAL should be able to share the same session between different virtual host junctions and standard junctions, providing the same session cookie is provided on each request. If different host names are used to access WebSEAL, then you need to enable the domain cookie within WebSEAL so that the same cookie can be sent to multiple hosts in the same domain.

    Oh no, this is working for me without problems, the problem is between any junction and the SAML.


    ------------------------------
    Gabriel Labarrera
    ------------------------------

    Original Message


  • 4.  RE: Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/25/22 03:56 PM

    Gabriel,

     

    > So, there will be always a login request when you are already logged in on any junction.

    No.  The SAML authentication will only be invoked if WebSEAL does not already have a session which it can access and use.

     

    > Oh no, this is working for me without problems, the problem is between any junction and the SAML.

    What do you mean when you say that the problem is between any junction and the SAML?  Is SAML authentication being used for authentication to the WebSEAL instance?  If so, SAML authentication should only be triggered when a valid WebSEAL session is not already available.

     

    Unfortunately I don't believe that I understand the exact nature of your issue.

     

     

     

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

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



     

     

     




    Original Message


  • 5.  RE: Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/25/22 04:34 PM
    > Unfortunately I don't believe that I understand the exact nature of your issue.

    To make it simple we have a SVA environment with some virtual and standard junctions with shared session via DSC, on that same WebSEAL instance we have a SAML IdP to login "Secret Server" users but when the user is already login on the junctions and tries to access "Secret Server" Verify request a new login, the same behavior happens when the user is already logged in on Secret server via SAML and tries to access any of the junctions a new login is requested.

    ------------------------------
    Gabriel Labarrera
    ------------------------------

    Original Message


  • 6.  RE: Shared session between SAML IP and Standar Junctions/Virtual Junctions on the same WebSEAL instance

    Posted 07/25/22 11:15 PM

    Gabriel,

     

    The SAML IdP should use the authenticated identity which is provided to it by WebSEAL.  So, I would check the session cookie which is provided to one of your junctions, and ensure that the same session cookie is provided to the junction which is hosting the SAML IdP.

     

    In other words:

    1. Access your junction, authenticate to WebSEAL and then look at the session cookie which is returned.
    2. Access the secret server, which in turn should trigger a SAML authentication flow via the WebSEAL server.  Look at the SAML IdP request and ensure that the same session cookie is being provided to WebSEAL.

     

     

     

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

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

     

     

     




    Original Message


Related Content