I have a .NET client-server system, which uses WCF for communication.
The communication must be secure. Up to now I used Windows Credentials for authentication.
But now a new requirement emerged - the system must work in a situation, when client and server are located in different domains (or the client isn't in any domain).
Windows Credentials authentication won't work in this setting. AFAIR, WCF supports following security mechanisms
Windows Authentication
X509 Certificates
Issued Tokens
Username and password.
Which of them should I use, if
I need to implement the fix with the least possible effort,
client and server are located in different domains (therefore, Windows authentication is not an option) and
the communication must be secure (the server must not process requests from unauthorized clients)
?
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 am working on a small service accessed from a client on Windows Phone 8 and/or WinRT device that requires a moderate amount of security. My goal is to create a service that runs in Windows Azure.
My application requires authentication that verifies two things:
1) Authenticity of the client
2) User credentials of the client
Step 1) I need be certain to a fair degree that the application calling the service is, in fact, my client application.
Step 2) The user needs to have an account in the system that can be authenticated. I can implement the authentication by simply making a Login() method in the interface (unless there is a better way). However, for this, the communication between the client and the server needs to be secure as I do not want my username+password combo unencrypted.
My current view is that implementing it as a WCF service would probably be the way to go as I might have further interest into porting to other platforms on the client-side and a quick look showed me that this is somewhat supported.
However, as I am new to all these certificate shenanigans, my question is whether I can use self-signed certificates for securing my connection? Only my server and my client need to be able to verify the authenticity. Furthermore, any pointers to exactly how this is done in the WP8 + Windows Azure case?
Another deal is that assuming that a nifty hacker breaks open my program from the client hardware, can he take the certificate and use it to create his own client to login with (his) username/password and performing actions performed by my original client? Or is there a way to prevent this on the client side? In other words, can my server be sure of the authenticity of the client software based on having a valid certificate signed by me?
Step 1 is pretty much impossible. No matter what attestation method you use in code it can be duplicated in code by another programme.
Step 2 doesn't require WCF, although you can use it with basic auth. It's just as easy to expose a RESTful service with WebAPI which supports basic auth as well. Securing the communication is the same for either WCF or WebAPI - use SSL.
WCF does not like self signed certificates, and configuring it to use them does away with some of the security, depending on how you do it. Given that SSL certs from trusted CAs start at around $10 it would be a false economy not to get one. Azure webworkers support SSL certs, and support for Azure Web Sites is coming, although with no firm date.
Finally a client certificate in managed code can be reasonably easily extracted, so you cannot rely on it to identify client code.
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.
This is our setup - our customers will have a database server with our database on and multiple clients running our frontend. We have some WCF services to allow the clients to request info from the database and each WCF session is authenticated with a username/password stored (encrypted) in the database. This all works fine and has been in use for a couple of years.
We're now adding the ability to sign in using a USB fingerprint reader attached to client PCs. For this we store each users' fingerprint template in the database and then upload them all to the device. The device can then tell us which user has presented their finger.
What is the best way to securely allow our fingerprint client to authenticate over the WCF service without using the user's password and without opening up the system to attack from unauthorised users?
My first thought is to define a secret key that both client and server know, encrypt it on the client with a timestamp and the logged in user id and send it to the server which can then confirm that the request came from our client.
Is this a good idea? Can an attacker just relay the same message to start an unauthorised session?
I'm not a security expert so I'd prefer an existing solution over rolling my own for obvious reasons.
We're using C# and only targetting Windows.
You could use an x509 certificate stored on the Client to provide the client credentials required for the WCF service. This would work in the same way that server security is provided via SSL certificates.
Some info on working with certificates:
MSDN - Message Security with a Certificate Client
MSDN - Working With Certificates
A word of caution would be that you would obviously have to manage the distribution and validity of certificates.
Th other alternative is to use the clients windows account for authentication purposes if the client machine is on the same domain:
Some info on working with Windows Account:
Message Security with a Windows Client