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.  IAG, multiple pods in Kuberentes

    Posted Wed October 21, 2020 05:37 AM
    Hello,

    I want to use IAG as my OIDC RP in Kubernetes. I got to make it worked with the help of people in this community. Now I am trying to get the best solution to it and I have several doubts:

    1. What is the best approach to deploy it? I am using a LoadBalancer service linked to the IAG pod.
    2. If I want to use more than one IAG pod, it will maintain sessions or do I have to change something?

    Regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------


  • 2.  RE: IAG, multiple pods in Kuberentes

    Posted Wed October 21, 2020 07:17 AM
    Hi Javier,

    An IAG instance creates an in-memory session for each connection (indexed by cookie) which maintains logged-in state after the initial SSO from the OIDC Provider.  When you deploy a cluster of IAG instances for High Availability (or Load) you should make sure that whatever is providing the load-balancing is set up for "sticky" sessions.  This is usually called "session affinity".

    The capabilities available for session affinity may vary by Kubernetes provider and by the type of inbound service you use.  Currently you're using a Load-Balancer service but you might also want to look at an Ingress (since this is HTTP traffic).

    The two most common types of session affinity are based on either Client IP address or on a cookie injected into the traffic.

    Using Client IP address for session affinity is the easiest approach but my give non-optimal results if the client IP address doesn't reach the load-balancing system.  This could be because of up-stream proxies - either at the client location or at your server side location.  It may prevent traffic from being evenly distributed.

    Using a Cookie for session affinity usually gives even load-balancing but it requires the load-balancer to have access to the HTTP payload.  This means it won't work for encrypted trafffic.  The load-balancer must either perform SSL-offload itself or have something up-steam performing this off-load.  This can be a security concern.

    I know this isn't answer but I hope it helps you look into the options.

    Jon.

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

    Original Message


  • 3.  RE: IAG, multiple pods in Kuberentes

    Posted Wed October 21, 2020 07:28 AM
    Hello Jon,

    it is a good answer and it was the one I expected (but I didn't want it). I am having problems in GKE using Nginx ingress and IAG because UNHEALTHY nodes so I was trying to avoid that solution. LoadBalancer services allow clientIP affinity but as you told me, it is not a good option. 

    Thank you very much for your help

    ------------------------------
    Javier Garcia Pazos
    ------------------------------

    Original Message


  • 4.  RE: IAG, multiple pods in Kuberentes

    Posted Mon October 26, 2020 10:37 AM
    Hello,

    about multiple pods, is IAG capable of use sticky sessions?

    Regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------

    Original Message


  • 5.  RE: IAG, multiple pods in Kuberentes

    Posted 26 days ago

    hello Team, is there any solution available when IAG has multiple pods? Having sticky session is not a good solution while going to cloud and containerized platform. Recently we discovered IAG doesn't preserve original url in session storage (e.g. Redis). IBM team acknowledged, this is a bug in IAG, and they are recommending to use sticky session in cloud platform to send request to same pod. Then what is the purpose of having a session storage. I see this issue is kind of reported in 2020 as per this thread, It's been 5 years, but there is no solution



    ------------------------------
    Bipin Dash
    ------------------------------

    Original Message


  • 6.  RE: IAG, multiple pods in Kuberentes

    Posted 26 days ago

    Hello Bipin,

    I know we've discussed this in the case but I wanted to clarify the current functionality for the wider audience.

    The original URL is preserved and stored in REDIS. We can see this via traces and by investigating the REDIS storage. The issue is that the OIDC state that's used to complete authentication is not preserved. This causes the OIDC authentication to restart and store a new 'original URL' which is the current '/pkmsoidc' endpoint.

    This happens until the OIDC authentication goes to the same IAG instance and completes the authentication flow.

    When the IAG ends on the '/pkmsoidc' endpoint because that is the updated 'original URL' it results in the 'Login Success' page to be shown since a 'GET' to the '/pkmsoidc' endpoint when the end user is authenticated causes the help page to be shown.

    So if you cannot use stickiness then the following is documentation for controlling the 'Login Success' page:
    https://www.ibm.com/docs/en/sva/10.0.8?topic=environments-controlling-login-success-response

    The following is documentation on using HTML Redirection:
    https://www.ibm.com/docs/en/sva/10.0.8?topic=redirection-preserving-html-fragments

    It describes updating the HTML to read a cookie and then redirect based on the preserved URL in that cookie.

    This was also suggested in the case.



    ------------------------------
    JACK YARBOROUGH
    ------------------------------

    Original Message


Related Content