IBM Security Verify

 View Only
  • 1.  Verify Access v10.0.2.0 released

    Posted Wed July 14, 2021 12:48 PM
    Edited by Jon Harry Wed July 14, 2021 12:50 PM
    Hi All,

    Just a quick post to make sure everyone is aware that IBM Security Verify Access v10.0.2.0 was released at the end of June.

    This support note describes the highlights of the v10.0.2.0 release:
    https://www.ibm.com/support/pages/node/6470203

    The IBM Documentation for the v10.0.2.0 release is here:
    https://www.ibm.com/docs/en/sva/10.0.2


    If you have Verify Access deployed in containers (or you're thinking about it), you might be interested that there are now "lightweight" versions of the Reverse Proxy, Runtime, and DSC containers which start more quickly, use less resources, and can run with little or no privileges.  I've updated my "container deployment" assets to use these new containers.  You'll find my assets on GitHub here:
    https://github.com/iamexploring/container-deployment

    The README.md of the repo includes instructions on using the assets for docker, docker compose, Kubernetes, Helm, OpenShift 3.x, and OpenShift 4.x.  There's also a link there to an updated docker and docker compose cookbook.

    One last thing: Verify Access customers are now also entitled to use the IBM Application Gateway.  It's a super-lightweight version of our Reverse Proxy that can bridge between an OIDC Provider and applications that don't support federation protocols.  If you're interested, check that out here:
    https://docs.verify.ibm.com/gateway/docs

    OK, I think that's enough links for now.  Thanks for reading.

    Cheers... Jon.



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


  • 2.  RE: Verify Access v10.0.2.0 released

    IBM Champion
    Posted Thu October 21, 2021 11:56 AM
    Hi Jon,
    Thank you for the announcement.

    We just installed 10.0.2 in our development environment, and we noticed a behavior change that does not seem documented.

    In some of our InfoMap Authentication mecanisms we are using:
    success.endPolicyWithoutCredential();

    Until 10.0.2, AAC was returning HTTP 200 even when calling the endPolicyWithoutCredential.
    In 10.0.2 AAC is returning HTTP 400 when there is a call to endPolicyWithoutCredential.


    I understand the logic behind this change, but as I am unable to find any documentation about this, I wanted to confirm it with you.

    Are you (or one of your colleageas) able to confirm that you have "fixed" this behavior in 10.0.2 , by making ISVA return HTTP 400 in this cases ?


    Thank you

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



  • 3.  RE: Verify Access v10.0.2.0 released

    Posted Fri October 22, 2021 05:12 AM
    André,

    I checked with development and they confirmed that the change to make this response a 400 in 10.0.2.0 was intentional.  It seems that the change slipped past the documentation update process for which we can only apologize.

    Is this causing an issue for you?  You didn't say whether it's a browser or JSON response where you're seeing the 400.  I would suspect (hope) that you would be able to override the 400 code back to 200 using server-side template page scripting if you need to.

    Jon.


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



  • 4.  RE: Verify Access v10.0.2.0 released

    IBM Champion
    Posted Fri October 22, 2021 05:24 AM
    Hi Jon,

    Thanks a lot for confirming what we thought.

    This is not an issue for us. Actually the new behavior is much more logic according to HTTP REST standards.

    We just had to adapt 2 of our mapping rules to use "endPolicyWithoutCredentials" only when the situation really requires it : for example when refusing to authenticate user because he entered an incorrect login/password or totp value.
    In that case, it's cleaner that ISVA returns a HTTP 400 instead of the previous HTTP 200. Our web applications had to check the content of the response to evaluate if it's an error or not. Now we just use standard http error handling.


    Have a nice day,
    André

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