Mutual SSL Authentication when Terminating SSL at the LTM

[Ryan Rank]

We are exploring terminating SSL at the load balancer sitting in front of our gateway cluster. We do have some APIs protected by Mutual SSL Authentication. That is, the API consumer calls the gateway and the gateway will authenticate the certificate presented to it via the request. So the authentication is between the API Consumer and the gateway.

We can inject the API consumer's certificate into a header at the LTM and I believe we can authenticate using that header. The assertions I have set up are basically this:

Request: Retrieve Credentials from Context Variable ${request.http.header.headerName}
Request: Authenticate against Federated Identity Provider
When hitting the Authentication assertion, I'm getting the following error:

Type not supported for variable credentials for variable request.http.header.headerName: Unsupported credential type: String. Exception caught

I've captured the header, and the PEM public certificate is in there. I can guarantee I'm missing something, but not sure what.

[Jay MacDonald]

SSL is point to point. If you terminate at the load balancer then the Gateway cannot access the security context, so it can't authenticate it. This is a limitation of the protocol. The only way around this is to extract the fingerprint of the certificate (or the entire certificate) at the load balancer and pass that as a header, but that is not actually an SSL credential any more, nor is it a credential that the Gateway recognises as such. All you can do at this point is a string comparison to a known certificate using policy, which must be hard coded in policy or pulled from a database.

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Ryan Rank]

Thank you for the reply, Jay.

Let's forget about true Mutual SSL Authentication for a minute (you are 100% correct in that it is point to point).

I was able to duplicate generally what I want to do using nginx so I'm not pestering my load balancer team. With the nginx configuration below, I can take the certificate presented and drop it into a header.

server {
    listen 8443 ssl;
    server_name localhost;

    ssl_certificate public.pem;
    ssl_certificate_key private.key;

    ssl_client_certificate ca.pem;
    ssl_verify_client optional_no_ca;
    proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;

    location / {
        proxy_pass https://gateway.company.com:8443;
    }
}

That approximates what we are considering doing at the load balancer. Using a regular expression to remove all the "\t" entries that nginx annoying inserts will convert it to a PEM format.

I can take the output of that regex and extract attributes from the certificate using the assertion of the same name. I was able to prove that.

Based on what you're saying, I cannot retrieve the certificate (credentials) from that variable and authenticate it against a FIP. Correct?

In the end, I'm trying to approximate a mutual SSL auth since what I'm talking about is not true mutual ssl.

I thought I was shown something to this effect years ago (Stephen maybe?), but my memory unsuprisingly fails me in the details. Or I'm just off my rocker.

[Jay MacDonald]

How are you using the FIP? Are you loading explicit certificates into it, or checking if a certificate is signed by the FIP as a federated model?

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Ryan Rank]

We are explicitly loading certificates for each individual user in the FIP.

[Barry Stern]

Hello Ryan,

This is basically what we do with our MAG solution when clients want to perform SSL offloading at the LB.
https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/mobile-api-gateway/4-2/configure-mag/configure-mag-with-load-balancers-that-terminate-ssl.html

In order to use a the Retrieve Certificate from Context variable assertion to use for Authentication against your FIP you first need to get your source in the the x.509 Certificate data type. 
Here is a sample policy that takes a base64 encoded PEM and uses the Base64 Decode to create a variable as x.509 datatype to be referenced by your Retrieve Credentials from context variable assertion.

Also Note: You need to make sure you are trusting the source sending the certificate.

WARNING:

 Only use certificate credentials from an entity that has proven that it possesses the corresponding private key (for example, from a digital signature or a TLS client certificate). Do not use certificates from unverified sources.

Barry

[Ryan Rank]

Thank you, Barry! That got me what I needed. I was able to use that policy snippet and authenticate against the FIP. I do know it's nowhere near as safe as a true Mutual SSL Auth (and will advertise it as such), but we can mitigate quite a bit.

[Jay MacDonald]

That's a better way than I was planning to show him. I forgot that Base64 Decode could take a PEM and generate an X.509 type variable.

The other approach is to only forward the serial number and issuer DN for the certificate and use Look Up Certificate to see if we know it already.

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------