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!
Related
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)";
I'm using jquery ajax to fetch data from an asp.net webservice. I'm wondering how I can secure it and have it work with jquery ajax. The service is part of my web application and to access it you have to be logged in to the application. However I'd like to further secure it. For example a consultant looking up all their customers in an autocomplete box is good, but they can instead send in some other consultant's id. What's the best way to secure this?
I've looked at this article here http://msdn.microsoft.com/en-us/library/w67h0dw7%28VS.71,classic%29.aspx . However, I don't know how to make this work with jquery ajax. Any help would be appreciated.
As far as I understand you want to make sure that you know the identity of the person using your service. If the web service is part of your application this should not be a problem by using cookies (assuming the web service is on the same domain as the site). See this e-book for some ideas.
Otherwise you could hand out temporary identifiers to the logged in members of your site which would be used in the webservice calls - this way even if the identifier is stolen, it can only be used for a limited time.
I made it more secure by using encryption. I encrypt the consultant's id when passing it via ajax, and decrypt it on the server side. Obviously I do the encryption on server side and pass it to client when rendering the page. And then ajax makes the call using that encrypted id.
I've built an application that uses jQuery and JSON to consume an ASP.NET .asmx web service to perform crud operations. The application and .asmx are on the same domain. I dont mind people consuming the read operations of the .asmx remotely but dont want people randomly deleting stuff!!!
I can split the methods i'd like to be publicly accessible and the 'hidden' ones into 2 web services. How can I lock calls to the 'hidden'.asmx web service to the same domain that its hosted in?
Thanks in advance.
Edit:
Can someone comment on this, seems plausible ( source: http://www.slideshare.net/simon/web-security-horror-stories-presentation ):
Ajax can set Http headers, normal forms cant.
Ajax requests must be from the same domain.
So "x-requested-with" "XMLHttpRequest" requests must be from the same domain.
There are two scenarios you need to secure with web services:
Is the user authenticated?
Is the action coming from my page?
The authentication piece is already taken care of if you're using Forms Authentication. If your web service sits in a Forms Authentication-protected area of the site, nobody will be able to access your web services unless they're logged in.
The second scenario is a slightly trickier story. The attack is known as CSRF or XSRF (Cross Site Request Forgery). This means that a malicious website performs actions on behalf of your user while they're still logged in to your site. Here's a great writeup on XSRF.
Jeff Atwood sort of sums it all up in the link above, but here is XSRF protection in four steps:
Write a GUID to your user's cookie.
Before your AJAX call, read this value out of the cookie and add it
to the web service POST.
On the server side, compare the FORM value with the cookie value.
Because sites cannot read cookies from another domain, you're safe.
In AJAX the browser makes the calls, so even if you were to check that the domain is the same it wouldnt be secure enough because it can easily be faked.
You need to use some sort of authetication/autharization tokens (preferably with a time out) to keep things safe.
Quick and dirty solution would be to use IP address restrictions to allow only your domain's IP address access via IIS.
Probably better would be using HTTP authentication. There are many ways to do this, I found Authentication in ASP.NET Web Services a helpful overview.
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
I am building a web based application written in ASP.NET and Flex. One of my biggest challenges is implementing security for the application in a flexible and maintainable way. This challenge is compounded when different technologies are involved. I'll try to describe what I have below.
The website is laid out as follows:
/mydomain.com/
Login.aspx
Default.aspx (hosts flex [.swf] application)
/Administration/
AddUsers.aspx
AddRoles.aspx
AddPermissions.aspx
etc...
/Services/
SecurityService.asmx
MapService.asmx
PhotoService.asmx
etc...
I am currently using forms authentication to secure the resources on the website. All pages/resources not in the /Services/ folder require an authenticated user and will be redirected to Login.aspx if they are not yet authenticated. The .asmx pages allow unauthenticated users. To secure these resources I throw an exception in the SOAP method. This avoids redirecting pages for SOAP web services which is not supported by any SOAP web service clients I am aware of. Finally, SecurityService.asmx contains a Login method to allow the Flex application to Login without redirecting to the Login.aspx page should the cookie expire for any reason. Because the cookie established is sent with any request to the server, including requests coming from the Flex application, this seems to work pretty well.
However, this still feels like a bad approach securing web services. I feel like I am using Forms Authentication for something it was not intended for. Specifically, I am concerned about:
This model will not work when the services are separated from the core website. This is a newly discovered requirement and I believe that Forms Authentication is not going to work well (if at all) without a lot more modification and trickery.
Clients other the Flex may require access to the services. Some of these clients may not even be able use cookies. If so, this model immediately falls apart. This is not an immediate requirement but it is known that this is one of the long term goals.
We will eventually (hopefully sooner rather than later) move to a REST based architecture (vs. SOAP) so any solution needs to work for SOAP and REST.
So, my question is.
What are the best authentication and authorization mechanisms for securing an application built on ASP.NET, Flex, and SOAP or REST web services?
Note: I am actively looking into OAuth; however, I am having a difficult time finding complete examples from which to learn. Additionally, I need to be able to filter the data returned for a given user based on the permissions that user has, OAuth seems to remove the identity of the user from the token. As such, I am not sure how OAuth applies in a fine grained security model.
Others may disagree, but I actually don't see a huge problem with handling it the way you are now; that's probably how I'd handle myself, at least initially. One way or another, even down the road, you'll probably want to keep the Flex app aware of the authentication state of the session, so if that means checking the ASP.NET session token directly, or some other cookie you set when you set that one, it seems like a fine and reliable way to go.
I do see what you mean about the services redirecting, but even so, with forms auth, it's not so much the service specifically that's handling the redirecting so much as the ASP.NET app itself. Later, should you need to use a different authentication scheme, you can consider that scheme's specific implementation considerations. Unless you've got concerns about using forms auth in general, there's probably no need complicate your approach simply because of the Flex client and Web services.
I admit I don't work with web services much, but what about requiring an access key as a soap header parameter? Any client app which can communicate with a soap web service is likely to have a low level API to modify the soap request, and use of the access key allows you to (in theory) limit the use of the service. Google, Amazon, and several other providers use this type of authentication for their web services and it seems to work very well.
This article seems like it might be a good place to start...
The WCF Security Guide published on CodePlex may help you there, if you are using, or can use WCF.
There's also Microsoft's Web Services Enhancements (WSE) 3.0 which I believe implements some of the WS-* security specifications.
Hope that helps.
If you move your services to another place, then the standard ASP.net authentication cookie can be re-used if both web apps have the same machineKey in the web.config.
As far as I know, FLEX will honour the asp.net authentication cookies because it will make http requests through the browser, which will pass the http cookies (including the asp.net authentication ticket) like a normal http request.
Have you tried securing your website and services using normal asp.net authentication yet?
I think it's best to have independent authentication systems - even if there are relations between the user and the auth tokens on the back end. They are different beasts that have differing capabilities and demands.
Use the normal forms based auth for the flex portion. That is good.
For web services, you could create a login method that returns some auth token which is used by subsequent tasks to execute. Or add a few fields to your web services (posted in the header or as params) to use a userid/password combo for authentication each and every time.
A side note: I wouldn't rely on a soap exception to handle authentication problems. But you wouldn't need to worry about the redirection if you send an auth token or user/pass with the WS requests.
EDIT:
RE: Comment-
Ideally there is. There are products out there (Tivoli access manager) that service those needs, but they are expensive.
I gave this recommendation because it eases the pain of allowing access to alternative clients and as long as you designed the services correctly it's stateless. It also gives you finer grained control over data level access on the service side of things.
See Web Services authentication - best practices?
Dave Dunkin wrote:
The easiest way to handle it across a
variety of platforms is to use HTTP
basic authentication and HTTPS for the
transport layer. WS-Security would be
good if your needs go beyond simple
username/password but the support is
going to vary quite a bit between
platforms. HTTP authentication is
supported by every decent SOAP
implementation.
and my Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.