Layer7 API Management

Hi there,

We want to check the CA of the client certificate without authenticating the client. According to our prototyping and also to the documentation, this is not possible because the "extract attributes from certificate assertion" can only be used after an "identity assertion" like Authenticate User or Group...

Of course, a workaround could be to always initiate the authentication knowing that it fails. Doing so, the certificate attributes are accessible. But this is not a clean approach.... Any other possibilities to get the CA of the client certificate? I think it should be provided as a context variable by the "Require SSL/TLS" assertion...

Regards,

Peter

You can use a Federated Identity Provider for the Authentication Assertion. When you configure the Federated Identity Provider FIP just add in the CA or Issuer chain for your trust in the 2nd step of the Dialog during creation. Next choose the option that suits the way that trust can be applied (I selected them all). Next chose it as a trust anchor.

When you run your next request through, I used Require SSL with client certificate, and use the Authenticate Against Identity Provider "The New FIP you created". You authentication should be against the CA or trust anchor your established in the FIP and not the clients cert.

To test this I create a Test CA as a signing CA from Task / Manage Private Keys. I then created Test User from Task / Manage Private Key. You then go to the properties of that key and Generate CSR and save the file to your desktop as TestUser. Then go back to the list of keys and click on Test CA and the button to the right Sign Cert save to the desktop as TestUser-WithTestCA. This will Sign the cert on the Desktop with the Test CA. The go back to the list of keys and select Test User select Properties. Then click on Replace Certificate Chain. Replace with the new TestUser-WithTestCA. Then in SoapUI import the TestUser.p12 (that you can export from the properties of TestUser in the key list). You can then add that keystore to a request to the gateway via https://ip:8443/uri . You policy should work without having to authenticate TestUser. The only authentication it is doing is that TestUser is not expired and that its trust anchor (entire chain if you have it) is valid.

Thanks Anderson.

I get your point that using the "Authenticate Against FIP" assertions makes life easier because no user or group must be created in the FIP... But still, we must create a FIP for each new CA or add the CA-certificate to an existing FIP.

The background of my question is that we're thinking of scenarios to use an external directory as information store for the client certificate authorization (because of various reasons which I don't want to explain here :-)). So the directory would contain the servicename (or id, resolving URL, etc.), the CA certificate and the subject DN of the client certificate. In all policies we'd use the same LDAP query assertion to check whether this client certificate is allowed to consume this service. For creating the LDAP query we simply need the subject DN and the CA certificate of the client certificate (without having to create or adjust a FIP)....

Your solution will work for this scenario, but the creation/adjustment of the FIP is somehow overhead in our scenario.....

Thanks and regards

Peter,

The following context variables are available in policy after using a "Require SSL or TLS with Client Certificate Authentication" assertion (note that the "Require Client Cert Auth" must be selected in the assertion):

${request.ssl.clientCertificate} Returns the client side SSL certificate presented by the requestor (this is an X509Certificate object.

${request.ssl.clientCertificate.base64} Returns the same certificate as above, but as a Base64-encoded string with no white spaces.

${request.ssl.clientCertificate.pem} Returns the same certificate as above, but as a PEM-encoded string; this is formatted in Base64 with newlines, enclosed in the following wrapper:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Is this something that you could use in your scenario?

I can probably use ${request.ssl.clientCertificate}... The best would be to extract the issuing CA (SubjectDN, serialNr., ...) and the SubjectDN of the client certificate. Is it possible to extract these information out of the x509 object?