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 ;)
Related
Please advise me on this.
I have both Wcf service (which will be responsible for highly secured data manipulations) and Web App in same Server and i will access this Web application (Which will consume this Wcf service for data manipulation) over internet.
1) Is this a good practice to have both in same server.
2) What WCF Security i have to choose either Transport or Message security.
3) What type of architecture i have to use (Eg: 3 tier or N- Tier)
I use VS2010 and .Net framework 4.0 and Sql Server 2008 for development.
Thanks in advance.
It is not a simple question to answer if it is a good practice to have the WCF service on the same server as the app. If you want ot shield the service as much as possible you could of course put it on a separate server behind the firewall only allowing the web app to access it. But then it does sound somewhat superfluous to create a service at all. Does it provide methods that should be accessible to a client? -- When determining the deployment scenario you also have to measure cost to security and scalability. More servers means higher costs both for buying the servers and for maintaining them.
I think you can use both transport and message security, but using message security you could transfer the messages on http, which means less traffic than https.
About the number of levels in your application, this also depends on the nature of the application. You might even consider CQRS or similar architectures. But if you have proper segregation of the layers and they only depend on the next layer you can always insert new layers if needed. Speaking of which: If you plan to use the WCF service as an internal DAL, you could also prioritize to just create a simple DAL with a proper interface, which could later be changed to a WCF service.
There are many good reasons for creating a web service and it gives you the opportunity of scaling on more servers later on, so I am definately not recommending against a web service, just saying that it might be overkill or introduce a larger attack surface in your application.
Performance wise you might get a boost by using tcp bindings rather than http, but connecting external applications is easier on http if some non wcf client is involved.
Perhaps this post contains more questions than answers, but you are the only one who can decide given the brevity of your description :)
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.
My employer is a software vendor for a specific market. Our customers integrate our system with others using web services. We use Microsoft technology, and our web services are implemented in ASP.NET and WCF.
The time has come to review our current set of services, and come up with company standards for future integrations. I am reading "Enterprise Integration Patterns," and I've also been looking a little bit at nServiceBus and Mass Transit. These may simplify issues like contract versioning and unit testing, but they seem to be most useful for providing an internal service bus, not for exposing services to external clients.
Our customers are on many different platforms, and require our services to be standards compliant. That may mean different things to different people, but I think it is safe to assume that they want to access web services described with WSDL.
In this scenario, is WCF the way to go?
WCF is by far the most standards-compliant stack on the Microsoft platform. The nice thing is that it's very flexible for different clients "out of the box", and if there are things that cause you grief, most of them can be changed via custom behaviors without too much trouble.
An alternative that I normally recommend is integration over AMQP between your message brokers. That was you can use the push paradigm instead of the polling one (which is very powerful and scalable in comparison)!
You'd set up your own broker, such as RabbitMQ, locally. Then you'd let your integration partner set up one. (Easy: just download it).
If your partner is integrating from the same data center, you'd be save to assume few network splits - meaning you could share the broker. On the other hand, if you are on different networks, you can set up the broker in federation mode. (Run rabbitmq-plugins enable rabbitmq_federation and point to the other broker)
Now you can use e.g. MassTransit:
ServiceBusFactory.New(sbc =>
{
sbc.UseRabbitMqRouting();
sbc.ReceiveFrom("rabbitmq://rabbitmq.mydomain.local/myvhost/myapplication");
// sbc.Subscribe( s => s ... );
});
, like you would do when not doing any integration.
If you look at http://rabbitmq.mydomain.local:55672/ now you will find the administration interface for RabbitMQ. MassTransit creates an exchange for each message type (sending such a message to that exchange will fan out to all subscribers), which you can put authorization rules on.
Authorization rules can be in the form of regex per user or it can be integrated into LDAP. Consult the documentation for this.
You'd also need SSL in the case that you're going over the WAN and you don't have an IPSec tunnel - that documentation is here: http://www.rabbitmq.com/ssl.html and you enable it like this.
That's it! Enjoy!
Post scriptum: if you are feeling up for an adventure that will help you manage all of your infrastructure as a side-effect, you can have a look at puppet. Puppet is a provisioner and configuration manager of servers; in this case you'd be interested in setting up SSL with puppet. First, order a wild-card subdomain certificate for your domain, then use that cert to sign other certificates: you can delegate that - see the rabbitmq guide where it states "Now we can generate the key and certificates that our test Certificate Authority will use." - generate a certificate-signing-request for the certificate instead of creating a new authority - and let RMQ use this for SSL - it will be valid for the internet.
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.
I'm trying to build a WCF self hosted service (eventually in a windows service) that will receive binary and text base messages from remote thick clients that have no accounts on my hosted machine. I'm trying to figure out both my binding options and security options, and in reading the patterns and practices guides, my head has completely spun around at least once.
The clients would be authenticated against a custom SQL based method, so I'd like to be able to pass that info in the initial login request and then set an authorization token of some kind. (This part of the problem is probably outside the scope of the question, but I included it in case it might make a difference.)
Any thoughts at all would be very helpfull.
Ryan
The choice of binding and security option depends on the usage of your WCF service. Is it just for your rich client or are you planning to expose it to the world as API? If it's just for your rich app, does it run on LAN or over untrusted, unreliable Internet?
With WCF you can configure the service to expose multiple endpoints with different bindings, for example both SOAP and REST. In general, I'd start with something stateless and lightweight like basicHttpBinding and webHttpBinding, passing user and password on every request. Once you have that up and running you can optimize cache authentication, provide binary endpoint etc.. only if it actually helps.
There's no need to have just one binding. Having said that if it's self hosted you're "on your own" here. I've never looked at what's involved.