I'm going around in circles with regards to WCF and security so i'm just going to shove a load of questions here and hope someone can help me gain a clear picture.
Can someone please give me a plain English explanation of Transport vs Message level security.
I think I have a service running under SSL that will authenticate the user based upon their windows credentials. I also think I understand how to limit access to a service method via the PrincipalPermission. But how do I actually retrieve the current IPrinciple, so I can return different results dependent upon who's calling the service?
I have figured out how to turn tracing on and I can see my trace logs using "Microsoft Service Trace Log Viewer" but ill be damned if I can figure out what Im being displayed. Is there a decent resource explaining how to use this thing?
When using the "Certificate" clientCredentialType, is this somehting different to SSL?
When using the "Windows" clientCredentialType how can I see what windows user is being passed through?
My requirements mean I have to use basicHttpBindings - Am I correct in assuming:
I only have Transport level security available to me?
I can not implement custom username/password for this binding?
I know these questions may seem stupid, but any help with clarification would really help.
EDIT:
How can I add custom SOAP headers to my service in a similar manor to .asmx services? Is this a valid approach?
EDIT:
Further to the above questions I would like to know if it is possible to authenticate a windows mobile device based upon its windows user by checking against Active Directory. For all that I have found so far it seems unlikely.
N.B. For those who do not know whats available for windows CE's version of WCF its: Transport level security only, and either none/certificate for the Client Credential Type. So it seems that CE's WCF wont allow this by default but could I securely send this information in the message (via the method signature) and would this be an acceptable way of sending this kind of information?
I don't know all answers but here are the ones I do know
transport security means the communication is encrypted while the message is transported so it can't be read and or tampered with. Message security means the contents of the message itself is encrypted the transport however isn't necessarily. Message security can for instance be used with HTTP while transport security would require the use of HTTPS (or other bindings).
IPrincipal principal = Thread.CurrentPrincipal;
no answer
Yes, although SSL itself uses certificates it's not the same. You can have the client send a certificate which is known to the service or which is signed by a trusted authority to that the service knows who the client is and whether to allow them to make the call or not. Using SSL will only ensure that third parties can't read the communication between the client and the services by intercepting the network packages.
IPrincipal principal = Thread.CurrentPrincipal; principal.Identity.Name;
No.
You have None, Transport, Message and Mixed security as your options however Transport security will require calling the endpoint using HTTPS since thats the secured version of the protocol
EDIT: Check out the discussion at this forum.
And the questions certainly aren't stupid.
P.S. I can recommend the book programming WCF services by Juval Lowy it's really in depth and comes with a really useful framework extending WCF/Simplifying certain things.
Check out WCF Security Guidance. If you need more information, you should be able to find it all there, its quite complete. Though it looks like #olle gave a pretty complete answer....
Also check these WCF Common Security Scenarios
Related
So feel free to not only answer this question but to throw out suggestions or improvements. I've never put together a large scale web application before. Here's my thought process:
Persistence Layer: Standard Database (MySQL right now)
Business Logic Layer: REST-like structure (PHP, Java Servlets, etc...)
Presentation Layer: Web Browser, Android devices (application not browser), and others
The reason I selected this architecture is so that devices can devise their own custom UI's and tap into the REST-like functionality by using GET, POST, and what not to interact with the server.
Problem 1:
The problem is, how do you secure user's information? You can authenticate the user over an SSL connection and return a special HASH so that the user can manipulate their account but if someone is listening on the network, all they have to do is listen for a REST call and steal the HASH. One solution is that all REST-like calls have to be over SSL, but this causes another problem.
Problem 2:
If the REST procedures are in SSL, the browser has to use SSL for everything which from my understanding can be slow and cumbersome when unnecessary. Also, SOP makes it impossible to use SSL ajax calls to the REST procedures from an unsecure browser. HTTP and HTTPS are considered different origins even though its the same origin, different protocol.
Is this solution viable? How would I solve these two problems? Or possibly (probably) is there a better architecture I should look into for my web application. Thanks in advance for all suggestions.
If you want to secure the information you have to use SSL, since anybody can listen the network, and see the user information. If you want to secure the access, then use HTTP authentication RFC2617. Over SSL, Basic is secure enough, but if you don't want to use SSL for every request, Digest is the way to go:
your application can be stateless: i.e. more restful, easier load balancing, ...
the authentication token can hardly be reused if listen (no session hijacking)
almost every HTTP client (browser or lib) can use basic or digest HTTP authentication.
As it turns out, there is actually no great solution out there for this answer. You can either protect everything with SSL or devise your own home brew authentication system. A common method is to send the user a unique HASH, store the HASH in the database and in a cookie on the client's machine. Then only that user's IP, User-Agent, etc.. will be authenticated to that cookie.
So the answer is yes, the solution is viable. Extra security precautions will need to be maintained in order to disallow account hijacking. SSL for login will protected the password. A unique hash will allow the user to continue being authenticated without giving away their password to the account. Storing a large amount of information about the user such as IP, browser agent, etc... will disallow easy hijacking of an account.
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
For a few reasons, the bunch I'm working for don't want to use certificates and don't like the idea of a service that can be accessed by anybody with a valid logon.
My question is how can I authenticate an application as being an official application suited for use with these wfc services without using certificates?
They are trying to avoid a situation where inquisitive customers are clever enough to retrieve the service calls and have enough infrastructure to build their own clients to use them.
I think this is hardly achievable. If you expose service you are just saying "Hey, here is some functionality you can use if you have valid credentials". Identification of calling application is just another data send in a message. So if you have clever customer who has valid credentials and valid IP (if you use some filter) he can just send the same identification from his own application. If you create some clever algorithm for creating random valid application ID you would still ship that algorithm with your client application so you would need obfuscation to secure its code from reverse engineering.
We used a magic number scheme in one job where we paired a generated magic number with a range of IPs. However we also used username passwords just one idea.
Something I can't wrap my head around is how secure web services are.
For example we're writing a desktop application that will interact with data on one of our websites as well as local data. This data is sensitive though and the last thing we want is anybody calling the web services.
I've not yet found anything that says web services has some kind of authentication methods and the only security I've seen people talk about is using certificates to encrypt the message.
I'm no guru on this and would appreciate anyone's input and perhaps a link to somewhere that will explain this in simple terms.
Thanks
Jacques
If you are using ASP.NET to create a response / request Service you have only 3 options
ASMX
WCF
Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps
Authentication:
Consider securing your web services with SSL. Distribute client certificates to those who need to consume those web services. Configure IIS to "Require Client Certificates".
Authorization: Consider developing a scheme where the user is sending a username and password of some kind in the querystring. When you can determine that those credentials are permitted to perform the operation that they're requesting, you can allow them to proceed. Indeed, this is custom logic that the application developer needs to write. There are no built-in conventions in ASP.NET web service for this.
The SSL encryption occurs at a lower level from the application. It's the applications job to then determine who is allowed to perform what operations.
Our webservices are encrypted through SSL (the certificates part) which is https://www.yousite.com instead of http://www.yoursite.com. This just provides basic encryption for the data stream. See SSL.
They are also authenticated by the authentication method that is chosen for our website. If it's is windows auth, or forms auth. See the msdn page on ASP .NET authentication.
For XML Web-Services you should take into account the following best practices:
Secure the transport Layer: the infromation or data in XML cannot be interrupted and read in transit.
Mask internal resources: Use Network Addres Translation (NAT).
Implement XML filtering: With the heklp of XMLand SOAP, affective filtering policies can be set to a content level that requieres a fully parsed or processed XML document.
Validate, Transform, Sign and Timestamp al messages: Use XML Schemma Validation, use XSLT for transforming XML, sing all messages, use Network Time Protocool (NTP) for synchronizing all XML nodes to a single authoritative reference time source.
Encrypt message fields.
Implement secure auditing.
Use existing security methods such as HTTPS.
Perform XSL transformations on the server.
Source: EC-Council Secure Programmer.
To expound on previous answers: Web Services are as secure as you make them. In general, there are two types of security. Securing the Transmission, and securing the access. Use of SSL can make your transmission secure (). Using Authentication (demand a username and password) allows you to secure access.
Web Services accessed via public internet (that is: not a VPN or only internal resources) are, indeed, less secure than Windows applications, since anyone can have access to them and, potentially, attempt to break your security. By using both transmission and access security, you can mitigate that to acceptable levels (acceptable to the point that banks use them for financial transactions, and you don't know paranoid until you've talked to a banker who has to face an FDIC inspection).
All web applications are exposed to the attacker and are a great surface area for attack. The biggest problem with web services, such as SOAP(WCF) is that often times the programmer doesn't realize that its trivial for an attacker to gain full access to the service. Often times programmers expose nasty functionally like execute_sql_query().
You should read the entire OWASP top 10.
Here's a primer on Securing XML Web Services Created using ASP.NET.
I've built ASP.NET Web Services in the past that either were publicly consumed, or used Windows Authentication. I now need to build a Web Service that uses the SOAP 1.1 protocol and it needs to be secured with a username and password from the caller.
It seems setting up the infrastructure for WCP is overkill for one or two Web Services. Any other suggestions? I was also thinking of using ASP.NET 4.0 Beta, if anyone has explored that for this scenario, it would be helpful to know your opinion.
Thanks in advance for your suggestions.
The simple way is to create a special header that carries the auth info for every call and authenticate/authorize the user that way
Here's some sample code:
http://aspalliance.com/805_Soap_Headers_Authentication_in_Web_Services
Note that in this way you are sending clear text username and password so you would want to use ssl or use some kind of digest authentication
There are different ways of doing this. One could be enabling access to a specific sets of IPs. If the IP doesn't match one of the lists then you could easy reject the call at method's level.
Otherwise, you could create another method that would return a token and then make all the relevant methods to expect that token in return in order to process the request.
Use SSL. Force everyone who consumes your webservice to use https.
//Check for Secure Channel: HTTPS
if (!Context.Request.IsSecureConnection)
return "The HTTP Connection must use Secure Sockets (HTTPS)";