IBM Cloud client certificate based authentication: Client certificate details to cloud - ibm-cloud

I have deployed liberty app on IBM cloud. I have setup custom domain and selected "request client certificate" so that clients have to send certificate to access app over TLS. I see client authentication does work, but I do not get any client certificate information in my app. This makes client certificate authentication a bit useless, as I would want to know the id of client which accessed my app. Any help/pointers appreciated.
I looked at attributes of request. Two attributes are passed in request _com.ibm.websphere.servlet.uri_non_decoded_ with value /dummyRelPath and _javax.servlet.request.cipher_suite_ with value of ECDHE-RSA-AES256-GCM-SHA384 There's no attribute with name javax.servlet.request.X509Certificate passed in request.

Does:
X509Certificate[] certs = (X509Certificate[])
request.getAttribute("javax.servlet.request.X509Certificate");`
not return any certificates?
In cloud foundry on bluemix, your client should be handshaking with a DataPower proxy. That proxy adds a custom header to indicate the TLS client cert that was provided, then it is passed through the CF gorouter, then finally passed to the JVM.
WebSphere Liberty then surfaces that through the API above.
This is communicated through the $WSCC request header. If the API returns null, it's most likely that header was dropped or never set by the infrastructure, rather than making it all the way there and the API mysteriously losing track of it. You could dump the request headers, looking for this one in particular, and maybe something will stand out (some surprise hop/proxy).

Related

Service Fabric Stateless api certification based authentication

I was asked to secure my stateless api endpoint using cert based authentication. I read about the subject, and realized I needed to create a middleware to inspect the request, and then check for the x-ARR-ClientCert header, to check whether the certificate is valid or not, based on some thumbprint. So far, so good.
The problem is that I can't test the middleware, because I don't have idea on how to send such a header. I already have a self signed certificate(.crt) and a key(.key). I tried with postman, but I can't see the x-ARR-ClientCert being sent while debugging on VS2017.
Any Help?
Edit 1
I'm following this tutorial: https://blogs.msdn.microsoft.com/kaevans/2016/04/13/azure-web-app-client-certificate-authentication-with-asp-net-core-2/
I know it's a bit old, but at the end the writer shows the browser asking for a certificate, but I just can't manage for the browser to ask for the certificate.
One thing I forgot to mention here, is that my API is on a local Service Fabric Cluster, so that might be the problem
Edit 2
For Postman, I've followed this tutorial: Postman Tutorial, but had no luck: first I had to turn off ssl check, and then when added the certificate to Postman, the x-ARR-ClientCert header wasn't being sent.
I've also tried curl: > curl --cert cert.crt --key client.key https://localhost/api/values --insecure but still the x-ARR-ClientCert isn't being sent.
I am not sure what you are trying to accomplish...
In a mutual certificate authentication, the browser handles the authentication\certificate exchange, and when the user tries to access an endpoint secured by client certificate, the server tells the client(browser) that it requires a certificate to accept the connection and the browser popup a message to the user asking for a certificate to be used, there is a nice write about it here.
If the plan is to do it for automation, the postman blog has an article on how you setup client certificates for this scenario. The other option is trying to send the certificate using CURL as described here.
Secondly, you are reinventing the wheel, there are already some ready to use implementations in kestrel using HttpsConnectionAdapterOptions.ClientCertificateMode = RequireCertificate and some authorization middlewares here and here.
And finally, make sure that there is no proxy in the middle or that the proxy or gateway is not removing the certificate from the client connection.

Accessing IBM API Connect endpoint through Postman

I just created an REST API in API Connect and the endpoint works when I test it in the APIC assemble tab. It requires a client id and client secret. When I send a request through Postman, I currently get a “Could not get any response” message from when I try to add them as header values or OAuth authorization. I’m using the request endpoint that’s displayed when I hit the debug button from the successful response on the Assemble tab. Is this the correct endpoint to use? How do I properly include the client id and client secret in a Postman request?
If you get a "Could not get any response in Postman", that means that Postman can't reach the destination of the request.
There are several reasons for that:
Is it an intranet or internet endpoint?
Are you using a proxy? (check proxy config)
Is the hostname resolvable? (try ip)
If it is an https
endpoint, with a self signed certificate, check if you have SSL
Certificate verification enabled (Settings-> general)
On the other hand, to send the client-id and client-secret headers, just click on Headers tab and add both (see the following picture)
Please check the below things to get access to API Connect published services.
Service needs to be allowed to invoke from postman(System from which you are invoking.)
Please check the web-api MPGW service titled in DataPower default domain created when you configure your API connect with DataPower have you created an access control list in the front-side-handler.
Please disable the SSL configuration in the postman, sometime this may create a problem(since the service exposed from API Connect will be with SSL)
From the error you are getting, I suspect there is no connection or only one-way traffic is enabled which means you are blocking response. If there is an issue with the request parameters you are sending, an error will be different saying, wrong client id or client secret.
Testing API which is on-boarded from API Connect will be straightforward or same we invoke other rest services.
Thx Srikanth
I needed to include the client id and client secret in the headers using the correct name for them, which is specified when creating/editing the api under the 'Security Definitions' category as 'Parameter Name'.
I was also hitting the wrong endpoint. To find the correct endpoint click the hamburger icon in the upper left of api connect website, select dashboard, click on the environment you want such as sandbox or dev, click settings, click gateway, then you'll see the endpoint.

Configure IBM Cloud Application with "request of client certificate"

I need to configure an application to accept connection only from client with a certificate, the client should be ApiGateway.
I followed this step by step tutorial. But when I should upload a certificate and enable a checkbox called "Enable request of client certificate" in upload dialog box it disappear.
I tried with many browser (Chrome, Firefox, Safari) on a Mac. I'm quite that this not depend on browser, so now how can do the same thing?
Thanks for every answer.
From my understanding, the given task needs to be separated into two activities.
Client with certificate
A client with DNS APIgateway
Client with Certificate
In general, when we create an API, we expose with a gateway via HTTP protocol which has some signed certificate (Production). Please provide that public certificate to the consumer of your API. And you can test this using postman, we have an option of SSL certificate upload in Postman, make a use of it for testing.
Client with DNS Name
For this, in Datapower (API Gateway), you can create an Access control list following this IBM documentation. Access control list is something, we allow or restrict the host that we consume the services exposed using Datapower.

Sending ClientCertificates from HttpWebRequest via Fiddler

I am trying to send out a WebRequest request like https://identityserver.github.io/Documentation/docsv2/advanced/clientCerts.html specifies with a handler containing the Client Certificate.
I've gotten to the point that i have determined that the ClientCertificate is just not being sent through fiddler, so it is not read in the ServerVariables["CERT_FLAGS"] when the Owin LoadCertificate is called.
So i have removed all the steps from the process except (IdentityServer3.Samples/source/Clients/ClientCertificateConsoleClient/Program.cs)
async Task<TokenResponse> RequestTokenAsync()
{
var cert = new X509Certificate2("Client.pfx");
var handler = new WebRequestHandler();
handler.ClientCertificates.Add(cert);
var client = new TokenClient(
Constants.TokenEndpoint,
"certclient",
handler);
return await client.RequestClientCredentialsAsync("read write");
}
but I am still not seeing in fiddler in the raw request the certificate. I have looked at the source code for HttpWebRequest and only see it handles the ClientCertificate in the GetConnectionGroupLine, and then its a hash code which i also don't see in fiddler. I'm working with Windows 7 and i have turned on the iis client certificate mapping authentication and enabled the setting in iis express applicationhost in the 2015 .vs subfolder and the primary one in my docuemnts. What am I missing here?
reference: https://social.msdn.microsoft.com/Forums/en-US/f88a23f2-3dbe-4202-baf2-a5b05b027fe6/httpwebrequest-not-sending-client-certificate-to-server?forum=netfxnetcom
https://github.com/IdentityServer/IdentityServer3/issues/3220 - can't really find this on stackoverflow..
TLDR: Your problem (at this point) is Fiddler not HttpWebRequest/dotnet. (Edited to clarify.)
Fiddler doesn't display TLS info including certs. Fiddler works on, and displays in numerous formats, the HTTP-level data (requests and responses, including application data). When HTTPS transports this HTTP data over SSL/TLS, Fiddler does not display the SSL/TLS-specific data, which in addition to server and optional client certificates (currently) includes version, suite, possibly compression, curve, format and next-protocol negotiation, nonces, ephemeral keys, renegotiation control, signature algorithm control, server name indication, ticket, and other crypto options like encrypt-then-mac and extended-master-secret. The "raw" tab displays all the HTTP data without interpretation, but not the SSL/TLS data.
Fiddler doesn't request client auth. An SSL/TLS session uses a client certificate to perform client authentication only when requested by the server, and when your client connects to the real IdentityServer it presumably requests this. But when Fiddler is used, there is one SSL/TLS session from the client to Fiddler, and an entirely separate SSL/TLS session from Fiddler to the server. On the session from your client to Fiddler, Fiddler does not request client authentication, so your client doesn't and can't send or use its certificate.
Client auth can't be relayed anyway. If Fiddler did request client auth on the session from your client, it couldn't use that information to authenticate the session to the real server. Client auth doesn't just send the client cert, it also uses the private key to sign the concatenation (called a transcript) of the handshake messages. Since the handshake between your client and Fiddler and between Fiddler and the server are quite different, this signature is invalid for the server-side handshake and sending it would (correctly) be rejected as invalid by the server.
Instead Fiddler can do the client auth. If you want to route HTTPS traffic using client auth through Fiddler, you need to instead configure Fiddler to do the client auth on the session with the server; for a fixed setting you can just drop the identifying certificate in Fiddler's config directory, for per-session settings you need to write some FiddlerScript. The private key (and chain) needs to be in the Windows cert store, not (just) in a file. See:
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/RespondWithClientCert
https://www.fiddlerbook.com/fiddler/help/httpsclientcerts.asp
Fiddler: Respond to Requests Requiring a Client Certificate (on SO)
https://security.stackexchange.com/questions/72916/can-fiddler-decrypt-https-traffic-when-using-elliptic-curves-client-cert-authe
If your actual problem is getting the client to support client auth when NOT using Fiddler, you need to take Fiddler out of the situation and use other debugging tools like a network trace.

Intercepting and forwarding client certificate to webservice

I have a web application (gwt) that is running on a tomcat application server. This web application consumes several web services (login, application data transfer, queries, etc.). The web service client on the tomcat is implemented as apache axis2 web service client.
For user log on I provide a form in the web application with username and password. This data are transmitted via web service to authenticate the user.
It is planned to change the hole authentication mechanism to client certificated based authentication. The authentication still should be done on the web service provider side.
So my system has three relevant components: the web client, the tomcat application server and the web service provider.
Every user of the application has its own private client certificate (PKI Token, X.509- Auth-Cert). When the user connects to the web application his certificate is requested.
How can I forward the client certificates for use in the web services? (The tomcat will not be responsible for authentication).
1.) Is there a way to intercept the request and extract the client certificates before authentication error occurred?
I found some information about Servlet Filters what sounds really good, but I’m not sure where to implement it to intercept the certificates before they are verified against tomcats keystore.
2.) If it is possible, how can I pass after the client certificate to the web service?
Thank you for reading
No, not really. The real piece used in authentication is the private key associated with the certificate, not just the certificate itself. And, typically, you have no way of retrieving that from the web client. Therefore, you cannot really pass-through the credentials you receive from a web client on to the web service client. The certificate itself is readily available, but is useless for authentication without the corresponding private key.