Any way to set value of request.ssl.clientcertificate without cert auth?

[Chris Bertagnolli]

Is it possible at all to populate the value of request.ssl.clientcertificate without actually performing certificate authentication?

We've got a fairly large Policy Fragment that does a lot of work parsing, validating and doing some magic for client cert authentication. However, it uses the variable request.ssl.clientcertificate so I can't use the fragment without using client cert auth.

What I'm trying to do is build a little functional testing tool for us to use internally. I just want to be able to take a base64 certificate, decode it as X509 and feed it through that Policy Fragment to make sure I get the expected end-result. That logic is pretty straight forward BUT I'm hung up because of the request.ssl.clientcertificate not being settable :(.

Was hoping maybe someone knew a magic way in the API GW to get that context variable set with a given credential.

We could change the fragment but that'd be a pretty big regression test and change to some existing policies. So was hoping to avoid that.

[Ozan Okan]

Dear Chris,
if I understand your case correctly it is possible. 

First convert context variable you want using Encode/Decode Assertion in Target select X509 Certificate then use Retrieve credentials from Context Variables Assertion and store to a message type variable. Then authenticate this message aganist the FIP identity provider you want.

I uploaded a sample policy attached, hope it helps.

Attachment(s)

certificateTest.xml   2 KB 1 version

[Chris Bertagnolli]

Thanks for the input. Unfortunately that still doesn't solve the issue since ${request.ssl.clientcertificate} appears to be null.

Since the actual request.ssl.clientcertificate variable contains no value then the Included Policy Fragment fails since it is explicitly required there.

Wish there was a way in the API GW to force an override of the "built-in" variables. Make this a lot easier :).

[Leandro Dantas]

You can use the http routing  assertion to accomplish it.

1. Create a private key in gateway to be your client key/cert 
2. Create a service to work as your client (e.g.: /test/client-service )
2.1. Add a Route via HTTP(S) assertion
2.2. Right-click the assertion -> Select Private Key

2.3. Select your client private key

Then, when gateway route to your service, it will send the client certificate in the request.

------------------------------
Sr. Consultant Services
HCL Enterprise Studio
------------------------------

[Chris Bertagnolli]

Not sure I follow how this would work? I don't have keys, only public certificates in PEM or Base64 and can't create keys for them. This is essentially to test "smartcard" log in since there's ~150 issuers and we don't have test cards from all of them - or when troubleshooting a specific cert issue reported by users being able to see if the cert passes all our "checks" or not.

If the API GW creates the key/cert pair I'm only testing that particular one and not the actual end-user certificate.

[Leandro Dantas]

Oh, I see. 

You can create a new cert variable and use this new variable in your policy.

For live code, you would need to copy request.ssl.clientCertificate certificate to this new variable. It will have a small penalty on execution because there is no direct way to copy the cert between variables.

if want to give it a shot, decode the base64 from a source ( a string variable or the ${request.ssl.clientCertificate.base64} ) to this new variable.

​

------------------------------
Sr. Consultant Services
HCL Enterprise Studio
------------------------------