I have couple of queries on protecting web services authentication https://<hostname>:<port>/authazws/auth?wsdl using certificate based authentication scheme.
I have had few ideas from the old post but still have some queries and started this new thread.
Protecting SPS WebServices Ujwol
I am in a understanding that the SSL needs to be enabled in SPS Apache level to achieve the cert based auth.
I would like to get your thoughts to correct to understand better.
Below is how my setup is:
In this scenario, how do we configure cert based auth to protect WebService based authentication traffic?
May be a basic question but I need your help to understand better.
Do you have any article which explain the basic about the certificate based auth scheme setup? I never tried it before so looking to get some hands on.... Any help?
So, you are saying SSL is terminated at LB and is not passed on to the Apache web server.
In this case, I don't think you can use X.509 client certificate authentication scheme. As, your LB will not pass the certificate to the Apache.
You should probably check your LB documentation if there is a provision to achieve this.
Yes.. I think we cannot achieve the cert based authentication here... Meanwhile, is there any article you can refer I shall go-through for generic cert based auth scheme setup?
Tech Tip : CA Single Sign-On :X.509 Cert Authentication with IIS Agent
Tech Tip : CA Single Sign-On :X.509 Cert Authentication with Apache Agent
Tech Tip : CA Single Sign-On :CA Access Gateway:X.509 Cert Authentication
Ujwol.. I am checking LB documentation and it looks like LB can send the it as a header . It means the LB will validate the certificate and decrypt the traffic. Optionally, you can have the LB add a number of request headers to the request detailing elements of the validated client SSL certificate. The web tier could one or more of these to implement additional check... Int his case what are the steps required at SPS end to protect the authazws using certificate.
Here, the federation traffic is remains same and the assumption is ssl related header will be passed only to the web services requests. Can this be handled in SPS and configure cert based protection?
My thoughts on this is you can achieve TWO WAY SSL handshake (i.e. X509 Client Cert Authentication) over a HTTPS channel only.
The discussion here is a design based one.
In this case SSL (HTTPS) terminate at LB, which is a ONE WAY SSL Handshake. If we need to enable Client Cert Authentication i.e. TWO WAY SSL handshake then we'll need to implement this logic at LB, this would keep the TWO WAY SSL handshake simple and functional at a single Layer (i.e. LB). Once LB verifies the authenticity of the client using TWO WAY handshake, LB can then send the request downstream to CA AG on non https ports (in this case CA AG would have AuthAzWS as unprotected). In this approach, the onus of protecting the unprotected / non SSL AuthAzWS is taken over by the LB completely. You'll need to PoC this and make sure everything looks good.
There is another good alternative. Multiple instance of CA AG can be installed on the same server. So we could leave the FED CA AG untouch as it, along with existing LB configurations. Build a new instance of CA AG on the same server for AuthAz. Here you can use SSL Termination on the new instance of CA AG. Which mean CA AG will also do the TWO WAY SSL handshake and protect the AuthAzWS using X509 Client Cert. This is an OOB Supported configuration, so you need not do a PoC.
I don't think the first approach will work. As to my knowledge I don't think LB can utilise client certificate authentication/protection logic on it's own. All it may be able to do is receive the client certificate, validate it and forward the certificate data to downstream (CA AG) as HTTP headers.
Second approach of separating this out into two CA AG environment is more straight foward.
Some LB's do support Client Authentication. CA's favorite LB does support it
Additionally it seems we could also separate TWO WAY SSL Handshake based off traffic.
But again this approach has some level of unknown and that is a risk which needs to mitigated by running a thorough PoC.
I'd still go for approach-2 i.e. using multiple instance of CA AG as that is OOB and CA tested.
Thanks Hubert.. I will check this and comeback if any queries.