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.
Related
I'm doing my school project and in my case, I have a client and 2 WCF cloud service in Azure cloud and the first service then needs to call another service. The client (caller) need to call the WCF service and verify the caller identity without Login, and what way can I use in this case, My idea is to use SSL Authentication or IP to verify the caller identity and is this method is correct or any suggestion method to this case?
There are multiple options for authentication. As you indicated you can use a SSL certificate to validate that the client is who you think they are (preferably SHA2 or above).
You can also white list by IP as you also mentioned. This could cause problems later if the there are multiple clients or their IP changes.
With WCF you can also use a Custom User Name and Password Validator where the client passes a user name and password in the request.
I think unless you have the option to use windows auth, tokens would be the other option, that is more complicated though. Using SSL or User Name Validator are probably the easiest to set up.
I was wondering if the twisted webserver offers the possibility to restrict access to some resources using client certificate based authentication and to allow access to other resources without certs.
I searched trough the questions and found this posting: Client side SSL certificate for a specific web page
Now my question is if someone knows if twisted has implemented the ssl renegotiation and how an example would look like.
Or has there been a different approach since then?
Just to make things clear and to give additional information:
What I actually want to achieve is something like this:
A new user visits a site and has not yet granted access to the resource because he has no token yet that allows him to view the site.
Therefore, he gets redirected to a login resource that is asking for a client certificate. If everything is correct, additional data retrieved from the certificate is stored in the session, which makes up the token.
He then gets redirected back to the entry site, the token is validated, and according to his authorization level specific content is displayed
If I understood you correct Jean-Paul, this seems to be possible to implement with your strategy, right?
Correct me if I'm missing something or doing it wrong.
It doesn't seem to me that SSL renegotiation is particularly applicable here. What you actually want to do is authorize a request based on the client certificate presented. The only reason SSL renegotiation might be required is if you want the client to be able to request multiple resources over a single persistent HTTPS connection, presenting a different client certificate for each. This strikes me as unlikely to be necessary (or at least, the reasons for wanting this - rather than just letting the client establish a new HTTPS connection, or just authorizing all your resources based on a single client certificate - are obscure).
Authorization in Twisted Web is straightforward. Many prefer a capability-like approach, where the server selects a resource object based on the credentials presented by the client. This resource object has complete control over its content and its children, so by selecting one appropriate for the credentials presented, you completely control what content is available to what clients.
You can read about twisted.web.guard in the http auth entry in the web in 60 seconds series.
This will familiarize you with the specifics of authentication and authorization in Twisted Web. It will not tell you how to authenticate or authorize based on an SSL client certificate, though.
To do that, you'll need to write something similar to HTTPAuthSessionWrapper - but which inspects the client SSL certificate instead of implementing HTTP authentication as HTTPAuthSessionWrapper does. This will involve implementing:
IResource to inspect the transport over which the request is received to extract the client certificate
implementing a credentials type which represents an X509 certificate
implementing a credentials checker which can authenticate your users based on their X509 certificate
and possibly implementing a realm which can authorize users (though you may have written this already, since it is orthogonal to the authentication step, and therefore is reusable even if you don't want to authenticate with SSL certificates)
This functionality would be quite welcome in Twisted itself, so I'm sure you can find more help from the Twisted development IRC channel (#twisted-dev on freenode), and I hope you'll contribute whatever you write back to Twisted!
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.
How to secure WCF service which an Android app will use?
Currently we are building an android app that will connect(by using SOAP) with a WCF service (made on another pc in console host)...
We actually want to secure this server so only people with right credentials can access the app?
How do we do this??? Do we need to use transport or message security... And can transport only use SSL or not??
And also is it better to use IIS for this or not..
Please help
Thnx
Start by configuring everything to use HTTPS (i.e., HTTP over SSL) so that your communication channels are encrypted. Then add some sort of login credential scheme so that clients authenticate to the server. The simplest is username and password. You can use Basic or Digest auth styles; both should be supported by both ends so the choice is up to you (and it's not so important which you choose since it is all inside HTTPS anyway).
All this is independent of which clients you use and which servers you use. (There's also various XML Security things that you can use with SOAP, but that's adding a lot more complexity for very little extra advantage; the big gain comes from going to HTTPS.)
First of all sorry for my English, its not my native language. I will try to describe my problem as much as I can.
I searched for a long time on the Internet for a solution where I can create a wcf service that can respond to requests of my clients with username and password required but without creating a certificate, using https or anything else that require a special configuration on the machine where my windows service will be installed.
Here is my point: I want to deploy an application to a lot of my customers. This application will have mobile devices and a server which will give some information to mobile device with the help of wcf. Each customer will have a server and many devices. I don't want that anyone on the web can have access to these information and for this reason, I must implement an authentication procedure with username and password for each request but I don't want to be forced to install a certificate, activate some https port on each machine when I sell a new copy of my application.
I've read that with wcf 4.0, there is a built-in system that can encrypt data and for this reason, I don't want the overhead of implementing anything else if possible.
My question is: Is that possible to have a secure solution considering my requirements and if yes, how can I do that?
If I really must create a certificate and use IIS, https or any other secure solution, it is possible to automate these things in a package that will be installed in a single click wizard into each server machine of my customers?
Thank you in advance for your time.
By default WCF doesnt allow transport of username credentials over http and hence have to use certificates to secure your transport layer. But if you are sure that you are fine with sending username credentials over the http channel then you can have a look at ClearUsernameBinding which gives you the flexibility of sending username credentials over http channel (consider the fact that someone can intercept your transport channel to get access to the credentials)
Also if you want to use certificates that have to be installed you can achieve that writing some code in c# and include that as part of your installation from your package. You can also configure everything from an msi like creating a virtual directory, deploying the application,etc..
what you are probably looking for is one of the wcf bindings that has message level security. You can put the user name and password into this message and not worry about them going across an http wire unencrypted(ie custom authentication). The defaults for WCF send user name and password as part of the http request in the header this is why it wants https.