I am hosting a secured WCF service (transport level security) which needs to authenticate users with third party client certificates. To accept those client certificates, I have binded my IIS7 with third party Server Certificate. Theoretically speaking this should work perfectly. But it is not, It continues to give error as
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
Does anyone having idea on how to make it possible in this case?
Check out the WCF Security Guidance on Codeplex - they have tons of How-To's and extensive coverage and step-by-step explanations for all things WCF security related.
The one How-To most interesting to you would probably be:
How To – Use Certificate Authentication and Message Security in WCF
Related
I have a microservices based web app. Microservices communicate with each other via a REST API exposed. I want an easy, yet secure solution to secure communication between my microservices. I've already used JWT protocol to secure my user-services communication but I can't figure out the best way to secure server-server communication.
Update:
I want an easy way to authenticate APIs. Is is a good way to hardcode key and secret or put them in configurations files and then use them to authenticate to an other end point?
I've heard about OAuth2 protocol but I'm afraid it's an overkill for my need.So What can be the easy and secure way to authenticate APIs?
You should use HTTPS in order to make communication between servers secure. As far as point to point security (transport layer security) is concerned this is the way to go.
But keep in mind that this still doesn't mean that you'll have message-level security (end-to-end security). Intermediaries (i.e. service agents or other services and applications) along the message path will be able to see what is in the message content while processing it.
REST relies on the uniform contract provided by HTTP, so you cannot use the advanced features of WS-Security as you would have with SOAP. The security features of SOAP provide a wider spectrum of options, so if security is key in your case, you should definitely check SOAP web services out.
Also, take a look at this question. It's relevant to yours and I'm sure you'll find it helpful.
Hope this helps!
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.
I am studying brokered authentication, federation etc. On all the blogs, it's mentioned that there is a "trust" between Security Token Service and other web services. However, I could not find a blog which explains how to establish that trust.
Questions:
Which thing makes other web services trust the STS? i.e. how do we establish trust between STS and other web services?
How do other web services verify that the security token is issued by the STS they trust, and not by some other STS?
I understand that various technologies would be doing it in different manner. It would be good if someone explains how it happens in the .NET world (using WCF, Windows Identity Foundation etc.).
It's done using the X509 Certificate.
SecurityTokenService (STS) "signs the SAML token" using a certificate which is trusted by other services too. So the trust is established using the common thing, i.e. the certificate, which STS, and other services also trust!
While calling other web services, SAML token issued by the STS is sent through the SOAP header. If the SAML token is signed by the certificate your other service trusts, then your service understands that the token is issued by the 'trusted' STS.
In Windows Identity Foundation, you can configure the signing certificate for STS.
In case of other web services, the trusted certificate can be configured in the Service Host using ServiceCredential class.
I think there's a gap in my mental model of WCF authentication, hoping someone can help me fill it in.
So, I'm creating a WCF service and would like to have clients authenticate using certificates, and message-level security. I'd like the service to validate these using chain trust so that I don't need each client cert installed on the service. For now, I'm not interested in having the service authenticate to the client.
Here's my understanding of what's needed to do this:
The client needs a certificate signed by a CA that's trusted on the service side.
The service needs a CRL installed for that CA.
The service config should have message security turned on, specify clientCredentialType="Certificate", and chain trust for client certificate validation.
The client config should have message security turned on, specify clientCredentialType="Certificate", and an endpoint behavior that tells how to find the client certificate in the store.
The client makes a request to the service, sending its certificate. The service sees that the client's cert is signed by its trusted CA and lets the request through.
Now, all of the walkthroughs of this process I've found also include a step of creating a certificate for the service. None of them explain what this is for, which is throwing me. Why is a service certificate needed if I just want to authenticate the clients?
You are right. In theory no server certificate is required, in practice wcf enforce you to use one. The good news is that you should use a dummy certificate for the server and also set ProtectionLevel to SignOnly. I suggest to read this article which talks on a similar scenario and mostly relevant.
I have binded my IIS7 with a third party 'Server certificate' (Not issued by my server).
I have deployed a secured WCF service on this server with Transport security.
When i try to consume this service, it only accepts those client certificates which are issued by my server (made using makecert). The third party client certificates just don't work here.
To my knowledge it should accept them as they are issued by the same CA!!
Any idea on how to make it work?
Seeing your configuration would help, anyway it seems that the WCF service (not IIS itself) is not configured to use your third party certificate, thus requesting your clients to have a client-side certificate issued by your server.
Take a look at this guide, it helped me a lot when I had to deal with this:
Link