IBM Security Verify

 View Only
Expand all | Collapse all

accept-client-certs behavior - Any way to omit mTLS cert requirement for certain paths?

  • 1.  accept-client-certs behavior - Any way to omit mTLS cert requirement for certain paths?

    IBM Champion
    Posted Mon May 08, 2023 08:56 AM

    We require mTLS certs on many of our webseal pools.  However, I have a case where I want to allow the embedded junction status app, exposed at say /jctstatus, to be able to be accessed by a local script (hence using a POP to control access by source IP range).  Is there any way, when [certificate] accept-client-certs = required is set, to allow access to a specific resource path without requiring mTLS?  Setting it to optional is not an option unfortunately, as it breaks some flows when the cert prompt can be cancelled.

    I fear the answer is no, but I thought I would ask.  I was hoping maybe there was something like the bypass permission on ACLs that could be set that I just wasn't aware of.  I hate the thought of having to generate, import/register the cert (associate with PD user), and maintain a cert long term for a simple script to fetch this information locally within our environment.

    Thanks for any input!

    Matt



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


  • 2.  RE: accept-client-certs behavior - Any way to omit mTLS cert requirement for certain paths?

    Posted Mon May 08, 2023 05:10 PM

    Matt,

     

    Unfortunately you are out of luck.  When the 'accept-client-certs' configuration entry is set to 'accept', the certificate negotiation takes place before any data is transmitted down the channel.  This means that the MTLS channel is fully negotiated before WebSEAL receives the request – which in turn means that WebSEAL doesn't have the option of deciding whether to force MTLS based on elements of the request.

     

    The 'prompt_as_needed' configuration option is meant to allow WebSEAL to decide whether client certificate authentication is required, but there is some TLS trickiness required in order to get this to work.  I have you investigated this option?

     

    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: accept-client-certs behavior - Any way to omit mTLS cert requirement for certain paths?

    IBM Champion
    Posted Tue May 09, 2023 09:28 AM

    Scott, that is what I was afraid of.  I was hoping maybe there was some way I wasn't aware of, since the required option can still present the error page to users when they do not supply a cert.

    The prompt_as_needed unfortunately is not an option since the login with cert button must be clicked.  Although I personally prefer that experience, these are instances with many legacy applications, including some system->system flows where certs are used.  Hence, these automated systems cannot "click the button" to login with cert.  If it was not for that, I would have pushed harder for the business line to change the user's login experience to prompt as needed, as I agree that is definitely the best way to go.

    I think what I am going to end up doing is writing a container based app that will have access to a private cert that is imported as a valid user into the ISVA registry that has access to the junction status path.  It will pass that cert during the TLS handshake to authenticate, and grab the contents of jct_status and then send it to our central logging service where it can be corelated with other junction information from the config container that I'll push with another app.

    I'll just have to deal with the private cert, which I'm thinking right now I am going to store in an ISVA keystore and let this new app fetch the snapshot from the snapshot manager like any other ISVA container and then it can grab that key from there.  Our admins are used to updating the certs (must be done annually) via the ISVA keystores so I am trying to avoid storing a key on this container app's config (i.e. as a secret in OpenShift, as a persistent file, etc.).  Hence, if I can keep the administration of the app familiar, I'll get more buy in from the team.

    Matt



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