How two implement mutual authentication between Client application & CA Gateway instead of OAuth

[Sanjeev Yadav]

How two implement mutual authentication between Client application & CA Gateway instead of OAuth?

Please provide in Details, 1)what I have to implement in CA API Gateway side 2) From Client application what details are required

Kindly give me in details 




Regards,
Sanjeev

[Francesco Mascioli]

Sanjeev,

did you had a look to the MAG?
It provides on GW side the services for creating/register client certificate and check the validity.
In the mobile side the SDK is able to manage the mutual authentication in transparent mode.

Regards
Franco

[Sanjeev Yadav]

I don't know the steps whether is client certification installation or something else! Please come with the proper answer:

Please let me know the steps in details of how two implement mutual authentication between Client application & CA Gateway instead of OAuth?



Regards,
Anirban

[Zhijun He]

The gateway supports client cert authentication, doesn't need anything else, but we need to setup few things,
1. the client should have a private key for client cert authentication, otherwise we can create a new private key on policy manager, and send it to client
2. the paired certificate needs to import into gateway on Manage Certificates, and associated to a user, assume that the user is in internal identity provider,
- on Manage Certificates, import the certificate
- create an internal user with username same as the CN of the certificate 
- open the properties screen of the user, import the certificate
3. configure listen port to "Optional" or "Required" client authentication
Task -> Manage Listen Ports -> double click on the port for https connection, click on "SSL/TLS Settings" tab -> ensure the "Client Authentication" is "Optional", or "Required"
(by default the port 9443 is set to "None" for client authentication, so it cannot be used for client authentication)
4. The api policy should contain following assertions for client certificate authentication:

1) Require SSL or TLS Transport with Client Certificate Authentication
2) Request: Authenticate User: <internal user name> from [Internal Identity Provider]

There should be another way to use Federated Identity Provider, we don't need to create user, but import the cert into FIP, and authenticate against FIP. But I don't have a chance to test/implement this solution yet.

Regards,
Mark

[Jay MacDonald]

Two things:

1. In most situations you do not need to import the certificate in the Manage Certificates interface. That is for a more generalised trust store in the Gateway. Identity specific certificates only need to be associated with the identity, which is why it must be imported into the IIP record. It is also possible to associate an explicit certificate with a user in an LDAP via the userCertificate;binary attribute in the inetOrgPerson schema

2. You should not configure the port to make certificates required. Doing so makes it impossible to use a one-way SSL pattern with the Gateway. By controlling the existence of the certificate in Policy you get the same control without the limitation. The SSL handshake itself does not differentiate. It will send the challenge no matter how the listener is configured for SSL.

I created a series of videos describing client certificate authentication that are available on YouTube.

#1: Explicit Certificate Authentication (https://www.youtube.com/watch?v=ZK0PPU3fQQQ)
#2: Federated Certificate Authentication (https://www.youtube.com/watch?v=bcCzLms_5UI)
#3: Working with Federated Identity Providers - Part I (https://www.youtube.com/watch?v=jlUDdieFvtw)
#4: Working with Federated Identity Providers - Part II (https://www.youtube.com/watch?v=iCfUeXfLHMA)

​

​​​

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

[Zhijun He]

Dear Jay,
At least the cert of issuer needs to be imported to gateway and has "Signing Client Certificates" option selected, otherwise there will be "No Client Certificate was present in the request" error even the client confirms it sends the request with client cert.

Please refer to the KB,
https://knowledge.broadcom.com/external/article?articleId=42881

Regards,
Mark

[Jay MacDonald]

Hi Mark,

Importing a signing authority and setting it as "Signing Client Certificates" is required for configuring a Federated Identity Provider. If you have an explicit certificate associated with the identity in a store like IIP or LDAP then you *typically* do not need to import them into the trust store.

That being said, there is of course an exception. If certificates are loaded in the trust store and marked for "Signing Client Certificate" then the Gateway includes a list of those certificates in the 'authorities' record of the SSL handshake which the client MAY use to decide whether it sends a client certificate or not. The idea is that the server advertises the authorities it supports so the client knows which certificate to use in the event that it has access to more than one - if it does not have one signed by an authority on the list then it won't send one, since apparently it will not be supported anyway right? The various SSL libraries handle this differently and it can cause a lot of confusion - the good old "it works for some people but not for others" kind of nightmare. Trust me, I've been down that path several times now.

Whenever setting up SSL and PKI in general, my mantra is that less is more. People tend to start loading in things or setting certs for uses that are not part of the requirement and that can manifest lower down in the system where it is hard to trouble shoot. If you are not doing identity federation, DO NOT mark any certificates in the trust store for "Signing Client Certificates". If you have a case where you have a federated identity provider configured with a signing certificate and you ALSO want to use explicit certificates that are not part of that FIP and the clients DO honour the authority list in the handshake, then you DO need to import every explicit certificate into the trust store and mark it as "Signing Client Certificates" so it is part of the advertised list and clients that honour the list will send it, which is a royal pain in the ass. Anyway, that is why I prefaced my point with "In most situations". :) To be honest, that scenario is quite rare so far, but the recent uptick on mutual auth deployments could change that.

Cheers!

JayMac

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