I have a tomcat application that invokes an IIS hosted ssl enabled, client auth enabled Webservice
This Tomcat application talks to multiple wenservices and probably each of them require client auth along with PKI authentication.
For the IIS Webservice the wsdl url can change hence I use
javax.xml.ws.Service(url,qname) constructor by passing the url for the wsdl ...
The thing is I need to call the above with SSL with custom client key. How to I tell the above constructor to use a sslsocket that I create with my custom KeyManager ? I do not want to use
HttpsURLConnection.setDefaultSSLSocketFactory as that will enforce other outgoing ssl connection to follow to my keymanager which is exclusive to the IIS webservice.
Thanks for your reply.
If you follow the answer to your similar question on ServerFault and make sure that Tomcat's <Connectors /> don't use the javax.net.ssl properties, setting your keystore for the default key manager might not be the end of the world. HttpsURLConnections will only authenticate with it to server that ask for it (client-certificate authentication is always requested by the server) and that ask for a client-cert from a CA list that would match your certificate's issuer. This might not be such a big problem in practice.
If you think it's too big a problem, there seems to be an undocumented property called com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory. Its documentation is as follows:
Set this property on the BindingProvider.getRequestContext() to enable
HttpsURLConnection.setSSLSocketFactory(SSLSocketFactory). The property
is set as follows:
SSLSocketFactory sslFactory = ...; Map ctxt =
((BindingProvider)proxy).getRequestContext();
ctxt.put(SSL_SOCKET_FACTORY, sslFactory);
THIS PROPERTY IS EXPERIMENTAL AND IS SUBJECT TO CHANGE WITHOUT NOTICE
IN FUTURE.
Related
Using latest VS 2013 and Azure SDK 2.4, I've created a Web Role and a WCF service in it.
This service will be consumed by a standard generated .NET service reference client proxy.
I am trying to figure out what is the simplest way to secure this WCF service. I mean securing the authentication can not be hacked easy way, like clear text pwd etc.
Some additional info about the use case:
There will be only one user
It is completely OK to store any secret in client side (like username/pwd or certificate) because the client app will run in a secured place
I just would like to prevent my service to be accessed by the public. Only my secured place running client app should access it, I would like no more no less.
So I am googling the web, and more I read more I confused and overwhelmed with the options and possibilities what I do not need I think. When searching for client certificate I find overcomplicated federated auth methods with server side temp certs etc what I am not sure my simple use case requires.
Any help appreciated.
Thanks in advance
If you really want to restrict access then I would look at client certificates. Configuring azure for client certificates seems quite complex to detail in a single SO post so I'll refer you to this blog post client-certificates-in-windows-azure and I'll summarize below [I used this myself recently so I know it works]
In essence you can make your own certificates using makecert [NOTE: you may want an official SSL cert for your site and only use self-signed for your client certificates.]
You then configure your site to accept client certs - normally I'd use appcmd.exe and a startup task but as the blog post points out your site is not ready so instead you need to add this to your webrole OnStart method [I actually went down the appcmd.exe path initially and was very confused].
using (var serverManager = new ServerManager())
{
try
{
var siteName = RoleEnvironment.CurrentRoleInstance.Id + "_Web";
var config = serverManager.GetApplicationHostConfiguration();
var accessSection = config.GetSection("system.webServer/security/access", siteName);
accessSection["sslFlags"] = #"SslNegotiateCert";
serverManager.CommitChanges();
}
catch (Exception ex)
{
...
}
}
In the CertificateAuthHandler you can than validate the certificate and if you want (and I recommend) that the client certificate being sent is from your expected CA (if self-signed) or that the thumbprint of the certificate is the one you expect (if there is only going to be one) or a combination of the above.
I have a server with SSL certificate and would like to implement a WCF service with username authentication. Can anyone point me to a simple current example?
I find lots that use the 509 certificate and I don't understand why that additional piece would be needed. I don't think I want to give the certificate I have for the SSL to the client either.
I think to use SSL is just setting up the web.config appropriately with wshttpbinding and using https: in the uri that calls the service.
In this case I will have only one or two users (applications at the client actually) that need to use the service so I don't see the overhead for building a database for the store for lots of login credentials or anything like that. I've read you can pass the credentials in the request header. I hope I can just have the service itself check them without tons of overhead.
I'm really struggling to get how a simple authenticate can work for a service but I know I need something in addition to the service being SSL encrypted.
Edit: Hummm having read more I get the impression that using https binding for the message circumvents any notion of username credentials without something mysterious with certificates going on. I hope I haven't wasted money on the ssl certificate for the server at this point.
Can the IP of the requestor be used to allow the service for a known client only?
If you only need a couple of users, then use the inbuilt Windows authentication - create Windows user accounts, put the right security option in your binding config and you're done. If you're using SOAP from a non-windows client you'll have to perform some tricks to make it communicate properly (typically we found using NTLM authentication from PHP client required the use of curl rather than the PHP SOAP client library, but I understand that if you use AD accounts this becomes much easier).
WCF docs have a full description of auth options for you.
We have a wcf service hosted in IIS. We like to restrict the client callers to known clients so we implemented a custom X509CertificateValidator. The service is configured with WSHttpBinding binding and IIS set to SSL and require client certificate. Everything is working as expected.
However, we found that we have other aspx pages hosted within the same site that should not require client certificate. It breaks our usage pattern.
I read that turning the IIS setting from Required Client Certificate to Accept Client certificate does not work. I tried this out, while still passing in the client cert from client and it seems to invoke my custom validator. However, using wcf proxy library, I'm unable to call it without a client cert to verify not passing one in.
If "accept client certificate" is not an option, what is the best alternative? Adding some type of message inspector?
Thanks very much in advance.
I have searched in vain for a straightforward example of calling a web service requiring SSL authentication and that has a self-signed certificate. I already have the code to be able to trust all certs, so you don't need to provide that. Just a simple example of being able to provide to the service the authentication parameters - username, password, and any other authentication-related parameters, transports, and headers necessary to authenticate successfully and make use of the service. Right now I am using Axis 1.4. Your responses will be greatly appreciated. Thanks.
Have you tried this?
https://stackoverflow.com/a/3256676/372643
You'll need to initialise your socket factory from an SSLContext that trusts this particular self-signed certificate.
Alternatively, you could import this specific certificate in your trust store (cacerts in your JRE directory), or import it into a copy of this file and use it as a global trust store by pointing the javax.net.ssl.trustStore system property to it (the default password is changeit).
I have a SQL Database which is storing my client side certificate for WCF service and other services. (X509 etc). I would like to use this Store (instead of 'My') to retrive this certificate (instead of declaring it in web.config) and then use it for WCF.
I have tried to search on this site and google but does not seems to be much of a help.
Currently I am doing
var targetEndpoint = new EndpointAddress(targetLogicalAddress, targetIdentity);
MyTransportPortTypesClient proxy = new MyTransportPortTypesClient("WebConfigSection", targetEndpoint);
So ideally I would like to get rid of the "WebConfigSection" and instead pass some sort of WCF object which has certifictate signed.
Does anyone know how to achive this?
I have finally solved this and Here's how I did it. (I'll share my experiece so everyone can use it) This is without using any machine CertificateStore. Its purely from Database to the client Proxy.
I have created X509Certificate2 Object and assign physical file (in byte[]). You can also put password if its password protected.
Then I have assigned the certificate to my proxy client.
Something like :
proxy.ClientCredentials.ClientCertificate = __MyCertificate
Now I have manupulated my clientproxy as I was inteneted to in my app.config. and that's it. All these properties will be in your proxy object.
Hope this helps.
AFAIK it is at least very difficult, if not down right impossible. WCF uses SChannel SSPI provider for the authentication and this SSPI provider will load certificates only from the SChannel CSP provider. In order to use a certificate from the database the certificate would have to be loaded first into a PROV_RSA_SCHANNEL CSP keystore and then the certificate context of this keystore would be passed to AcquireCredentialsHandle. For instance, this is how database mirroring is able to authenticate using a certificate stored in the database. While it is possible to do all these steps in managed code too, I'm not sure if is possible to plug them into WCF: I expect it is, but probably not for the faint of heart.