Is it possible to use mutual authentication (client SSL certificates) with WSO2 ESB? (I'm not talking about WS-Security.)
I see that it is possible to add custom keystores to the ESB but I could not find any information on how to specify what client key to use when connecting to a specific backend.
Yes. You can enable mutual authentication for ESB proxy service. Here you want to do small configuration to enable mutual authentication for all proxy service . You can edit axis2.xml file and change following property to "require"
<parameter name="SSLVerifyClient">require</parameter>
More details you can find here. However, if you are enabling mutual authentication for given set of proxy services, There is some more to do.. More details you can find here. There was an issue with older release in ESB. therefore you need some patches to install. but with 4.7.0 and 4.8.0 (next release). there have been fixed.
It is actually quite simple to set up mutual SSL authentication between the ESB and a back-end server. This requires configuration of the back-end server as well. Because the ESB serves as a 'client' when initiating a connection with the back-end, the back-end server is responsible for requesting the 'mutual' SSL instead of one-way SSL. See this nice mutual SSL article for reference [1].
In order to successfully use mutual SSL with a back-end server,
Load the back-end server's public certificate into the default
truststore, which is located in: repository/resources/security/client-truststore.jks (That's it!
That's the only change necessary on the WSO2 ESB side.)
Load the public certificate from the WSO2 keystore into the back-end server's
keystore.
Configure the back-end server to request mutual SSL.
If you're using a CA certificate instead of the default self-signed certificate, skip step 2.
Cheers,
Colin
[1] http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
Related
I'm studying for this exam identity & access management. The question is what is the difference between one way authentication and mutual authentication? Our prof says mutual is TLS but if I search on the internet TLS is also one way authentication... So I'm a bit confused
I have implemented both one-way and mutual SSL in Applications hosted on Java and Webmethods technology. In One-way authentication, there is a server certificate that the client receives, trusts it (registers it) and sends back a secret along with the server certificate. Hence, a successful SSL Handshake occurs.
In mutual SSL, in addition to trusting the Server Certificate, the Client also provides it's own certificate to the Server. Hence, a mutual trust is maintained between the Server and the Client after which the secrets are transferred.
TLS is a protocol for guaranteeing security in the exchange of information. It is used in particular on the HTTP protocol. The TLS protocol allows both unilateral authentication and bilateral authentication (or mutual authentication). Recently I published on GitHub a project that implements a system of Mutual Authentication based on Apache 2.4 and the TLS 1.2 protocol. https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/
The attached image shows the call to a REST service in mutual authentication
One of my teammate just enabled SSL on one of the service that we are using and I had to install a Certificate that he gave me to each of the client machines who intend to consume that service. Now, I am not very well-versed when it comes to SSL security and that raised a question in my mind that
WHENEVER we create a SSl enabled service, do we have to hand out certificate to all the clients
Is there any kind of configuration using which we create an SSL enabled service without having to hand out certificate to all the clients?
IF it is possible then how secured that service be than the service which requires each client to install certificate on the machine?
Also, is there any easy to understand article on WCF SSL security?
Que : WHENEVER we create a SSl enabled service, do we have to hand out certificate to all the clients
Ans : No. For SSL enabled service one do not need to handout certificates to clients.
SSL certificate on server (in this case service) side gives confidence to clients that they are talking to legitimate server.
Clients needs certificates only in case of when service needs its clients to prove their identity using client certificate. With client certificate server (service) gets confidence that its sending data to legitimate clients.
Que : Is there any kind of configuration using which we create an SSL enabled service without having to hand out certificate to all the clients?
Ans : Certainly there is way with which you can make service enabled without requiring client certificate. Check SSL Settings option for website where service is hosted.
Que: IF it is possible then how secured that service be than the service which requires each client to install certificate on the machine?
Ans : Obliviously using SSL certificate doesn't stop any clients from consuming it. Any client who knows service endpoint can consume it. Client certificate is one way to authenticate clients. Only those clients who has valid client certificate will be able to consume service.
Que: Also, is there any easy to understand article on WCF SSL security?
Ans : Check out this link : https://msdn.microsoft.com/en-us/library/ff650862.aspx Its WCF regarding security as whole and not just SSL security.
I am having an issue where service calls that I am making cannot validate server certificates presented by the TMG as part of connecting to the service. The certificate URLS from the TMG address are not reachable from the target servers. This is causing 30 second timeouts for new connections.
Is there a way to disable certificate revocation checks in Mule to avoid this issue?
If you're talking about Mule HTTP endpoints, then this would vary, if you're using http transport you can create a custom message dispatcher and allow http client to ignore the certificates, otherwise you can manually install the certificates in the keystore so you don't get SSL errors.
I am trying to get the WSo2 ESB to proxy over to a WSDL based service. The service is hosted in a remote server and the server requires mutual SSL handshake. It seems that the WSO2 esb is not able to present a certificate while renegotiating. Has anyone else encountered this?
Please follow the steps given in the following blog post [1]
[1]http://www.soasecurity.org/2010/07/ssl-profiles-in-wso2-esb.html
WSO2 ESB has a file under repository/resources/security called client- truststore.jks. This file lists all the Certifying Authorities (CAs) that the ESB will recognise as valid when transacting over HTTPS with clients who have certificates verified by these CAs. Export service certificate and import it to "client- truststore.jks". I hope it help you.
I have two WCF Services using WsHttpBinding with transport security mutual certificate authentication that are being hosted on the same windows server. Clients that can access one WCF service should not have access to the other WCF service. I need some help on configuring the client certificates on the windows host. The client certificates are signed by trusted CAs and the intermediate and root certificate chain is already installed on the the server. It seems like the service automatically relies on chain of trust and does not require the actual client certificates installed on the server at all before letting the client access the service - this is not the behavior I want. Can someone please tell me how I should be configuring these client certificates in order explicitly allow access to one service and not the other?
Thanks.
That has nothing to do with certificates themselves. When using mutual SSL authentication certificates are used only to authenticate client and the authentication is done outside of your application (this is difference to message security where you can create custom certificate validator). Once certificate is trusted client is automatically authenticated to anything on the server using certificates for authentication.
You are looking for authorization - the step where you define what can authenticated client do with your service. You can either hardcode your authorization logic into your service by using role based security or you can implement two custom ServiceAuthorizationManagers and assign each to single service.