An exploratory question, here. After some reading, I'm getting a sinking feeling that WCF's authentication options aren't "friendly" to non-Microsoft clients, or require a great deal of effort to implement. I'm building a REST WCF service for which I wanted some kind of simple digest authentication; e.g. I store a username and password in Web.config and share that with the team that will use the service. The team that will consume this service is a legacy shop not versed in Microsoft tooling or helpers; e.g. ANSI C/C++, PHP, etc.
Anyway, MSDN tells me that digest authentication requires that the server be in a domain. I don't want or need this service to be in a domain. That seems like an odd requirement. So I dismissed that option.
So I read about NTLM and Windows authentication, but I worry that I'd be imposing a burden on the other team by only supporting Microsoft-flavored, proprietary authentication methods; won't they have to put forth a lot more effort to code against such a service? These methods seem intrinsically tied to concepts like Windows domains and user accounts, etc.
If you just look for "friendliness" then you can go for basic authentication which is pretty much supported everywhere.
However, unless that is coupled with some kind of transport level encryption then passwords will be transferred in clear text - a pretty bad situation security-wise.
NTLM and kerberos authentication is supported by several non-WCF technologies does but a burden/requirement on the environment in which the are used.
You could look into some kind of message level authentication meaning that the credentials will be part of the message instead of handled by the transport. WCF supports the WS-* specifications that relate to message level security. Those specifications are again not tied to WCF or Windows.
I sounds like the simplest way in your setup would be to use basic authentication and use HTTPS for the transport.
Windows Authentication is intended for use in intranet services where there is a domain controller you can use to manage your credentials and authorization.
You need to check the Forms Authentication, that will probably meet your needs.
Related
Secure webservices in WCF
Background
We want to create a secure WCF service that has does encryption/decryption of data. The nature of data that will be encrypted and decrypted requires the highest level of security possible.
Consumers of this service will be applications within our network. The will be asp.net websites, other wcf services, console applications and possibly java based applications running on linux
Consumers will be running on local computer accounts that dont have any domain membership.
I have done a lot of reading about wcf security and do understand the concepts to a large extent. I am looking for a reference architecture that has worked well for others with similar needs.
Question
What authentication method should i use given that the new wcf service cannot depend on any database etc to store credentials, and also cannot depend of consumers to be members of a windows domain. I should be able to identify the consumer correctly within the service because the functionality will change slightly depending on who is the consumer.
What type of transfer security should i use- transport/message/mixed? Do any of these have performance considerations?
What else should i be thinking about?
Use client certificates for authentication. To identify a customer use message contracts with a custom header. Each client should put some unique value into the header.
I suggest using transport security in your case. There are two main drawbacks of using message security: Performance and which is more important to you Interoperability as you said you may need to support Java clients. You said you already read a lot about WCF security but just in case you missed it, here is a good article on Transport and Message security.
Pay attention to your service binding. I suggest using basicHttpBinding taking into account possible Java clients.
Hope it helps!
EDITED:
The header value should be a private one. Only you and your client should know about it. It's like what if I know your Gmail password, it will not take long to find out your login.
If you don't think it is secure enough you may skip custom header and map each client to an IP or a set of IPs. For example, IP 12.32.456.10 corresponds to client A. Then you can store this mappings in custom config file section and you can encrypt this section so that even people who has access to your service files can't get the mappings.
Don't forget to mark the answer as helpful if it is ;)
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
I'm in the process of setting up a WCF Data Services web service and I'm trying to sort out the security configuration. Although there's quite a lot of documentation out there for configuring WCF security, a lot of it seems to be outmoded or does not apply to my scenario.
Ultimately, I am planning on managing authorization of operations via change interceptors. Thus, all I really need is the simplest way to permit a client to pass credentials along with a request and to be able to authenticate those credentials against either AD or an ASP.NET membership provider (I'd much prefer the latter unless it makes things much more complicated).
I'm intending to manage encryption at the transport level (i.e. HTTPS).
I'm hoping that the eventual solution does not involve a huge web.config. Likewise, I'd much prefer to avoid writing custom code for the purpose of authentication.
In the following links you have a series of OData authentication options. If you don't know exactly what you want then that is a really good place to start and see what options you have.
Part1
Part2...
I am implementing wcf web service hosting in IIS with basicHttpBinding those should be accesseble by .net 2.0 client like accessing ASMX services.
Any body can help with details & with few example/sample code.
thanks
nRk
WCF is more secure than ASMX and insists the basic fact that it never allows you to send plain-text credentials without encrypting those.
You need to ask yourself a few qusetions here:
how do I protect my messages going from the client to the server, so that the username/password is not sent as plain text?
how do I check the validity of the username/password once the message arrives at the server?
For the first point, you can do a number of things:
secure the transport layer, e.g. use HTTPS (with SSL) to protect the entire pipe going from the client to the server. In that case, you don't have to do much else - the whole communication channel is protected
secure the message (at least the username/password part) using encryption. In that case, you need to have at least a service certificate on the server, so that the calling client has a shared secret to encrypt the message - or you need to install a certificate on the client (usually not a good idea if you want everyone to call your service)
For the authentication part, you need to decide on:
using the ASP.NET membership subsystem which already has a user table against which you can validate the credentials provided
or roll your own from scratch - not recommended unless you really really have to and have a very specific need
WCF security is not an easy topic - you can find helpful information and scenarios on how to do certain things here:
WCF Security by the MIcrosoft Patterns & Practice group
Declarative WCF Security by Juval Lowy
With just the few pieces of information you provided, one cannot really give a "do this and that" kind of answer. You need to read up on WCF security and decide on what scenario you want to implement. I'm sure folks here can help you with more specific questions about how to achieve certain things in WCF security, if your questions are more focused on a particular problem / issue.
I am writing a Silverlight application that will be both reading and writing data to a serverside database via some WCF web services.
What is the best way to secure these web services?
My goal is to make sure the services can't be called by other applications and potentially spammed with requests to add items to the database. Only the Silverlight application needs to be able to access them.
Don is absolutely right that there's no foolproof way of making sure that the client is a Silverlight application.
However, I think you're asking more about the following: Can I make sure that only people I trust connect to the service.
The answer here is (basically) a yes, or at least we have standardized ways of doing this.
You're typically going to want to consider a couple of different approaches:
Transport level security. Has somebody tampered with the traffic? We use SSL for this.
Authentication. Am I talking to someone I trust? Here, we'll typically use one of the authentication mechanisms (Forms Auth, say). You can use Forms Authentication to secure both Silverlight (actually the page that Silverlight resides on) and the WCF services. Confusingly, SSL can be used (though rarely is because it's a pain in the neck) for authentication.
In general, you can't assume anything about the client. If you try to keep non-Silverlight apps from hitting your site, a malicious client can easily pretend to be a Silverlight app, and you're back to square one.
That is to say, this is not an effective way to secure a server. To secure your server, assume that any and all clients will hit your site, and start from there.
Edit:
Let me amend that to say that if you want to get into the world of mutual authentication, you can set up a PKI to manage certs, issue user certs for all your users, and then you know who your users are. Still, one of them might be malicious (and talented) and inject a cert into another client.