IBM Security Verify

 View Only
  • 1.  Standard junction with token verification

    Posted Wed June 01, 2022 10:40 AM
    Hi,

    I am trying to integrate an application on Reverse Proxy by creating a header based standard junction using the application server details.
    But the application team doesn't want to trust the iv-user header sent with the request. Instead they are asking us to send a token in the request and provide them with an API URL to verify this token and provide access to the user. This is something similar to how oauth works.
    Do we have options to make this happen for a standard junction on webseal?

    Thanks in advance for any tip on this.



    ------------------------------
    Abhishek Kumar
    ------------------------------


  • 2.  RE: Standard junction with token verification

    Posted Wed June 01, 2022 06:16 PM
    First, ask "why?", then ask it at least 4 more times. The junction itself can be MTLS-protected between the WRP and the app. Asserted, authenticated end-user identity is what the WRP is all about. There are other options than just providing a cleartext username in the iv-user header, such as JWT (https://www.ibm.com/docs/en/sva/10.0.1?topic=solutions-json-web-tokens-in-http-headers), however ultimately they achieve the same thing.

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------



  • 3.  RE: Standard junction with token verification

    IBM Champion
    Posted Thu June 02, 2022 09:33 AM
    I had to laugh when I saw Shane's response, it was perfect.  If your junction is using SSL/TLS and setup for mTLS authentication, then the iv-user header is as strong as anything else and easiest to implement in my opinion.  But, your app team likely wants JWT as Shane described, as I run into this a lot where I am.  I typically try to steer the apps to using our ISVA OIDC solution instead of using the JWT HTTP header method, as OIDC provides them greater flexibility if they ever need to integrate with a different IAM system in the future.  If they want to consume JWT from the HTTP headers, then use the embedded JWKS app to provide them the signing key information so they can verify the JWT.  All the details are in the link that Shane mentioned.

    ------------------------------
    Matt Jenkins
    ------------------------------



  • 4.  RE: Standard junction with token verification

    Posted Tue June 28, 2022 06:48 AM
    Edited by Abhishek Kumar Tue June 28, 2022 06:51 AM
    Hi,

    I have integrated the application using this and I can see the token being sent by taking a pdweb.debug trace. 
    The application team now asking us a request url that they can call to verify the token. They are looking for an api URL which they can use to get a response on the verification. But the ISVA documentation only gives information about the embedded application which can be used to see all the Keys but nothing else on how to generate request for the verification. URL - https://hostname/jwks.json

    Do you guys have a suggestion here? Do the application team have to create a logic at their end to verify the jwt or do we have any other way to make this quick?

    Regards,
    Abhishek

    ------------------------------
    Abhishek Kumar
    ------------------------------



  • 5.  RE: Standard junction with token verification

    Posted Tue June 28, 2022 07:21 AM
    It would be expensive (network-wise) to call back to ISVA just to do JWT validation, even though this could definitely be done via the STS. There are many open source libraries for validating a JWT if the application programming platform doesn't support it natively (WebSphere does for example). We do not recommend anything in particular. This is pretty standard stuff in most modern programming frameworks. Your application team should research something suitable for their application platform. If they think that is hard, go back to MTLS junctions and have them consume plain text identity headers.

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------