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)";
Related
I have asp.net Web services, and I use them in my site using JS ajax calls.
I would like to set up a security mechanism (of any type) that will allow only users surfing the site to call them, and not just anyone requesting from those webservices.
How can I do that?
Thanks
Have a look at Building Secure Web Services.
A simple way will be to know the IP address of your site and then check whether its same as
HttpContext.Current.Request.UserHostAddress
Allow access only if both matches.
You can use ASP.NET Authentication.For more on authentication in webservirce check this
I have implemented security to my Webservices with Web Service Enhancements 3.0. There are many basic examples on the net that you can check out. But basically you want every Method to be called through a Post instead of a Get, and you would send a SOAPHeader with every HTTP call. The service/method checks the SOAPHeader validates and returns valid content only if the user is authenticated/valid.
Good luck!
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.
We are looking to secure a bunch of ASP.Net 2.0 .asmx web services. The which will host the web services is already forms authenticated.
Is it possible to secure the web services using forms authentication?
What are the pros and cons and other possible ways to achieve this. We certainly don't want to pass a username/pwd or token in each web method call.
The thing with form authentication is that its designed for people, where as a web service is designed to be consumed by a client application. While it is possible to do the authentication like this, it's the wrong way of thinking.
The level of security needed obviously depends upon the sensitivity of data that you're working with, but I'm going to assume its at least somewhat sensitive (but less than bank transactions). You could perhaps use SSL and passing a username and password as jle suggested, while I was typing this, or you could require an api key much like flickr does.
Another more secure option is to only pass the username and password once (and with the security of ssl) and have that give out a token that is valid for a period of time. This has the benefit of protecting the password information, and avoiding the constant overhead of ssl.
As mentioned though, it highly depends on HOW sensitive the information is that you're trying to secure.
WSE is obsolete. Do not use it unless you have no choice at all.
Almost all the functions of WSE are implemented better by WCF. The remaining capabilities, those not implemented by WCF, are obsolete themselves (DIME, for instance).
It is possible, but you will need to redirect users to a login page. Another option for passing username/pw is to use the web service over ssl. If you encrypt the connection, basic authentication can be used no problem.
You should be able to use WSE to secure your service using forms authentication - though personally I've never had to do it.
Here are some resources using WSE:
http://aleemkhan.wordpress.com/2007/09/18/using-wse-30-for-web-service-authentication/
http://msdn.microsoft.com/en-us/library/aa480575.aspx
To not use WSE you'd need to implement something like this as some of the other presponders have alluded to, though I'm not sure how reliable it would be:
http://www.dotnetbips.com/articles/dbd724e9-78f0-4a05-adfb-190d151103b2.aspx