Configure IBM Cloud Application with "request of client certificate" - ibm-cloud

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.

Related

Setting up clientCredentials Endpoint Behaviour on WCF-Custom Send Adapter

I am trying to wrap my head around how this should be set up correctly. I have two certificates, a client certificate and a service certificate. I've placed these in the MMC, on the service account for the host instance that handles the send port. So the client certificate is placed in the Personal folder and the service certificate is placed in the Trusted People folder.
I've tried using several "Find" methods to locate these certificates, such as thumbrprint and serial number, but I always get a "Certificate not found" exception back.
My current settings on the adapter.
Client certificate:
Service certificate:
My settings for Authentication:
SSL Certificate Authentication settings:
What is the correct way to add the certificates to the different stores, so that they can be located by Biztalk? I've found the MSDN documentation on the topic, but it doesn't really provide any answers: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/wcf/clientcertificate-of-clientcredentials-element
You have to be logged in as the BizTalk Service Account to manage Certificates. Run As doesn't typically work.
Other than that, the instructions should be correct.

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.

IBM Cloud client certificate based authentication: Client certificate details to 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).

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.

REST Service - SSL Implementation (HTTP Error 403.7 - Forbidden)

In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.