Can anyone explain to me when a certifate is require using WCF and authentication. From my understanding although i could be way off :-)
basichttp doesn't require a certificate to do authentication is hosted in IIS and using SSL otherwise a certificate is required
All other bindings like netTcpBindings etc require the use of certficate - is this true?
Or does it depend on what type of authentication i am using?
I would really appreciate any info or maybe a table telling me when a certifcate is needed.
I have a number of scenerios i am investigating like hosting in IIS or hosting in WIndows Service..
And i just can't seem to find the info i need
THanks in advance
There are two scenarios where you need a certificate:
A server side certificated that is used for SSL. For basichttpbinding, if you are sending a username and password over the network you should use SSL.
A client side certificate if you are authenticating clients using certificates.
Other bindings may use machine keys and certificates in the operating system, but you do not need to install a certificate for them to work.
Related
What's the easiest security mode for implementation in WCF when:
Both client and service are .NET applications.
Client and service are negotiating over internet.
SSL in not available.
Port 80 (web) is preferred for communication.
And Using a x 509 certificate should be the last option (same credentials in configuration file at both sides is preferred, if possible)
Security means a lot of things:
Authentication
Authorization
Confidentiality
Integrity
To name a few. You need to decide what are your requirements for each.
Since SSL is not available you must use message level security. But assuming machines do not necessarily live on the same windows domain you cannot use windows authentication and must use x.509 certificate, at least on the serve side. So:
<customBinding authenticationMode="usernameForCertificate" />
where the client authenticates with a username and the server with a certificate (client need to install this certificate).
You could also use a WSHttpBinding with all default settings except:
messageClientCredentialType=UserName
In which case client does not need to install the certificate, it gets it automatically in runtime via negotiation.
Both client and service are .NET applications.
Take a look here http://msdn.microsoft.com/en-us/library/ee707353(v=vs.91).aspx
I'm implementing an SSL layer for a web server project. I'm using polarSSL, though I think this question is a general SSL question.
When I get a connection to my server from a client I configure the SSL protcol like this:
ssl_set_endpoint( &mSsl, SSL_IS_SERVER );
ssl_set_authmode( &mSsl, SSL_VERIFY_NONE );
E.g. I'm not verifying the connection from the client. Do I need to do this?
Most browsers don't have client side certificates - though some do (I think). Is there any need or advantage for the server to verify the client? This is for a service where I would happily serve the data to a client that had no client side certificate at all.
Client-side authentication in SSL/TLS is used when it's required for the server to know its client. For example, it's widely used in banking, to access custom corporate servers etc.
In opposite, the common web server is intended to serve wide audience and not care about who's coming in. So client-side authentication is not used unless you know that you need it.
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.
The ColdFusion documentation is weak on how and when to use it. What does it do? How does one use it?
Update: it seems to be broken, as outlined in Washing Client Certs in ColdFusion with SOAP – Part 2.
problems with CFHTTP handling SSLv3 sessions
Client certificates are a bit of a pain because of the overhead involved in using it.
As Jura says, you'll need a target server that uses client certificates as a mechanism for authentication. This server side piece does not need to be CF-based. The web server (IIS, for example) would be set up to require this. This is part of the SSL/TLS protocol, not specific to any language at the application level.
You would use this if the server you are requesting a resource from requires client certificates. The administrator of that server would need to give you the client certificate and private key ahead of time. As mentioned by user349433, this is commonly a PKCS12 (.p12 or .pfx) file.
The server will validate that the client certificate is "trusted" and if it is, it will allow the TLS/SSL handshake to proceed, and CF will be able to write the HTTP request on top of it.
The use case today is to prevent man-in-the-middle attacks, but because of the overhead involved with certificate distribution, revokation, etc. it's not terribly common.
If you want to know more about it, check out TLS 1.1 specification:
https://www.rfc-editor.org/rfc/rfc4346
https://www.rfc-editor.org/rfc/rfc4346#section-7.4.6
You are using client certificate in case if the target server uses that mechanism for authentication. You'll need to obtain specific client certificate from the service provider in order to be able to connect to the service. It's been used for some internet banking applications back in days I believe. Not sure what is the use case today for it, may be distributed corporate networks where you need to connect to corporate server over internet in a highly secure manner?
I have a client/server WCF application that needs some sort of user authentication against a database. The application (both client and server together) is being developed to be sold to dozens of customers, for use on their intranets. We're not too worried about encrypting most of the data moving across the wire, except of course during authentication.
Thinking about WCF security, I keep coming back to the idea that we should be making use of x509 certificates. However, our customers will definitely not want to know about any of the details of having to apply for, purchase and install these certificates.
I'd like to know first of all what the preferred method is of implementing username/password authentication in this scenario. If it will require using certificates, must the customer apply for their own certs from a trusted CA, or can we as the software provider generate certificates for the customer to use?
Really I'm looking for a best practice, with the least friction to our customers.
Thanks!
Edit: I'm using NetTcpBinding, and my server is running as a Windows Service.
So username/passwords does not require client certificates as I'm sure you're aware, it simply requires an HTTPS certificate on the server hosting the WCF service - once you have that you can happily use the standard username/password auth bits (WCF will not allow message based authentication without HTTPS).
If you wanted to head down the client certificate root you get the advantage of non-repudiation - you can be sure that the machine sending is who it says it is (unless someone has stolen the certificate, which is less likely than a username and password combination going walk about). You as the software provider could act as your own certificate authority and generate your own client certs (there are a few ways to do this depending on your infrastructure) but then you need to configure the clients to trust your root CA.
If the server and client are running in a domain environment you could use transport security with Windows authentication (you're using tcp binding, so interoperability is out the window anyway!) The added bonus to this is the authentication is transparent and you don't need any certificates anywhere. If you want verfication of the server identity then message security with Windows authentication will do the trick.
I've got project in production which is similar to your scenario. I have a Windows Service hosting endpoints via netTCPBinding and I used x509 certs... although in my case, the intent was to encrypt both the transport and message layers, as I was crossing over untrusted security boundaries. I was less concerned with providing authentication/authorization other than requiring the certificate be present.
Similar to your intranet scenarios (I'm assuming), I had authority over the server and client machines at installation time... or at least could dictate some of the terms of installation.
Rather than purchase the x509 certs and burden the client with that expense, I opted to roll our own. We set up one of our Win2003 servers to be a CA, issuing our own Certification Authority cert. We then generated an x509 cert for the server, as well as individual x509 certs for the clients.
The client and server certs were installed on both clients and server (as appropriate) into the personal user store at the computer level. We also installed our CA cert directly into the Trusted Root Certification Authorities section, thus making our client and server certs trusted.
Because I was less concerned with authentication/authorization, I don't know what to recommend as a best practice for dealing with binding certs to individual users and going more granular than machine-level (my solution was windows service to windows service communication -- completely unattended). I would think you'd need a cert for each user, installing it into their personal user store in the certificates MMC. The runtime implementation will be guided by how you configure WCF to do the cert lookup, so it should be fairly easy.
Throughout the process, I relied heavily on what I'd learned from this great CodeProject article: Securing WCF Services with Certificates. It walks you through generating/installing the certs. The sample WCF applicatoin is IIS-hosted, but I was able to pretty easily translate the config sections from web.config to app.config.
In my case, I exposed the Web interface for requesting certificates in Win2003 to the web itself, so the client could request certificates directly in the future. We have approval control, so it works well. I haven't had a need to generate new certs yet, so I can't say how much friction that would entail.
If your going to be crossing firewall boundaries then certificates are going to be your best solution. I don't know much about the specifics about applications for certificates or your application. Unfortunately, as far as i know, i think you will have to help them apply for certificates or they will have to do it their self unless they want to undertake in the process of installing their own certificate server. If the app will be internal then windows authentication will work and is VERY easy but if you think your going to have clients that user your application across firewall boundaries then you might as well invest the time in using certificates because certificates will work everywhere. Now there is something called federated security where you delegate the permission of authentication to another entity. I think this is used if say you have to domains and you want to delegate permission say of someone on another domain that is not on your domain to their domain but its pretty complex and my understanding of its very limited but by the sound of your requirements certificates is the way to go.
Security is not supposed to be easy :)