I am moving from ASMX web services across to WCF. With ASMX, for security purposes I passed a password as a parameter to my web methods. I'd like to introduce a better layer of security going forward. Theoretically an attacker could decompile my application that consumes the web service, extract the password and consume the web service maliciously. Can I make it in some way so that the web service can only be consumed by my client application and not by any other means including a decompiled version of its executable? Does WCF introduce any any superior security methods? I notice that the client object that consumes the web services has properties for credentials. What exactly are these properties and how are they implemented?
A good way to add security, when using WCF, is through message security (WCF also supports transport security but this has some quirks) which is configured in the binding on an endpoint, very straightforward. With this security you authenticate clients via a username or password or even a SQL membership store (with the correct configuration)
Check this example out:
http://dotnetmentors.com/wcf/wcf-message-level-security-by-example.aspx
Biggest benefits are quick bolting on of secure messaging and not having username and password parameters on your operations!
Related
I am looking to host a WCF service accessible to a limited set of clients over the internet, as described here:
Best way to secure a WCF service on the internet with few clients
I intend to use Username/Password auth (using existing membership infrastructure) at this stage, with transport security (i.e. SSL).
I'm wondering what the recommended approach would be to processing the authentication request, when the membership database is obviously internal to the corporate network.
Options I'm considering are:
the public firewall would do SSL offload, and then the DMZ server would reverse proxy the request to the internal WCF server - I'm assuming credentials would be retained and passed through with this method, and the internal service could appropriately make use of the Membership provider to authenticate the user.
Write a dumb WCF service to sit externally which will make use of custom username/password authentication. This will call an Authentication Service internal to the network with access to membership details. Once the credentials are validated the call will then basically be passed through to the internal service that implements the required functionality.
Are both of these options possible? Are there any major pros/cons with either of them? (obviously reverse proxy is a lot less code...)
I have decided to use the second option. I already had a membership service internal to the firewall, so I will create the service to sit in the DMZ and implement a custom UsernamePasswordValidator and use it to call the membership service to validate credentials (and down the track I can then implement a custom ServiceAuthorizationManager to check roles/permissions).
Assuming credentials validate appropriately, the service will then call the main service internal to the firewall to carry out the functionality.
I'm starting in .net and wcf services, sorry if what i'm asking is wrong or has nosense. By the way, sorry for my english too.
I'm trying to build several WCF services hosted on IIS where the internet clients can login with their username / password (info stored in db). When they are logged, they can access their info, see their private documents, change their profile and more actions related to their account.
Well, in asp.net if I get the session after success login, i can build services like "GetMyDocs" and i know "who is", just checking the session username stored with the session ID when he calls the login and his session don't timed-out. But i've noticed that WCF Services are stateless, so this seems i have to send in all requests the username / pwd and check them in the DB before executing the service... always!?
Later, if i want to build a client desktop / Android / iOS application, i will use those services. They then can manage their personal and private data through those apps after a success login.
How should i handle this?
Are WCF Services the way to go or WCF aren't a good choice for that?
How can i handle the user identification with WCF? Because all my services are linked to a user and "GetMyDocs", "SaveNewConfig", "PayItem"... needs to identify who is calling.
Thanks in advance!! Regards!
But i've noticed that WCF Services are stateless
This statement is kind of wrong. Because you could easily create a "WCF-based" web service with state enabled. Furthermore, state is such a broad term that is not worth covering here. For example, you could use session state with a WCF service, or you could set the InstanceContextMode property of a service to one of the following:
PerCall
PerSession
Single
and of course, it all depends on how you configure the service itself.
If your service needs to be consumed by different clients, you should consider at implementing a RESTful service along with OAuth 2.0 or something similar where you can authenticate a request using the Basic Authentication header or by issuing an access token after a successful authentication.
There are a number of ways to provide authentication to a WCF service. One of them is by using a session (basicHttp does not support session, you have to use wshttp, or any of several other transports that support session). However, enabling session is a huge amount of overhead simply to avoid sending credentials on each request.
Session reduces scalability by quite a bit, but if you aren't worried about it... it's an option.
I have a .NET MVC web application with a custom forms authentication implementation that uses a FormsAuthenticationTicket embedded in an HttpCookie to manage session-based security.
We are expanding the system and the .NET MVC server layer is now going to call a secondary layer of WCF services (using HttpClient to call RESTFul services using JSON payloads). The secondary layer of services will be accessible over the internet and must therefore be secured.
What is the best way (and simplest way) for me to secure the second layer of services so that the first server layer can most easily and securely access them. Could I simply embed the existing HttpCookie containing the FormsAuthenticationTicket in the request to the second server layer?
You can secure the channel with ssl and use server authorisation mechanism for it.
I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.
I am building a wcf service that needs to be secured as information that the client inter-exchanges with the service is sensitive to the company. I am planning to have it hosted on iis6. What would be the best practice to make sure that nobody but the client application can call the service to get/set data?
The service calls need to happen under the user's real identity as all the calls have to be monitored and audited. I am planning to use PolicyInjection for audit calls.
It all depends.
But basically there are two main approaches:
Transport security with SSL with basicHttpBinding
SSL security with wsHttpBinding
If you provide more information, I should be able to help you more.
There are certain aspects of security:
1) Data integrity: no-one has tampered with data but the data itself are not secret. This is achieved by signing.
2) Data security: This is so that no one could see sensitive/secret information. This is by encryption.
3) Authentication: this is by sending username/password or using certificates. This makes sure the person is the same who is claiming.
4) Authorization: This is to make sure the person has access to the specific features in the service.