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
Related
Hi I am building a centralized authentication structure for all our applications in our intranet.
I have tried using a Jwt Web Api.
I have tried Identity Server 4 OpenConnect
And now i found out Cookie Sharing from Microsoft docs
https://learn.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2
I can't decide even after reading so many articles already which one should i implement.
The cookie sharing sounds very simple to do, I downloaded the sample and it worked right out of the box.
The identity Server 4 samples all have some problem that i can't run. Some functions like log out won't work or only works on one end.
The Jwt Web Api wasn't very hard to implement but still requires to thinker a bit to get claims from the token and then implement token refresh.
The cookie sharing i just found out but i'm still open for more alternatives or pros and cons each of these.
I also heard about OWIN but still don't understand exactly what it is
AFAIK
Cookie Sharing
If all of your applications are on the intranet and are all made using the dot net stack. It makes sense to take advantage of the sharing cookies. I previously had success implementing SSO using this strategy where the main login would be an old web forms application and it would authorise a dotnet core app.
Pros: You are using the Microsoft stack, easy to setup.
Cons: You are locked to using the Microsoft stack. Falls over if you want to use with native/js applications.
IdentityServer4
Having experimented quite a bit with this library, this is an abstraction of the OAuth2 and OpenIdConnect protocols, essentially authentication and authorisation using jwt tokens. IdentityServer4 allows you to specify your authority (AS => Authentication Server) which is handles authenticating clients (your other applications be it .net, js or native). The token that the AS gives the clients are then used to determine if the client has access to the an API. You get to specify which clients can access which api's and how much of it can they access based on Claims. It is possible to convert Active Directory groups into claims and authorise by that level.
Pros: Really good abstraction they simplify a big part of the process. You can secure any type of client (js/native/.net).
Cons: You still have to learn OAuth2 & OpenIdConnect specs, which can take quite some time. You'll probably endup writing quite a bit of configuration depending on how big the network of apps that you are trying to secure.
JWT Middleware
This just allows the api to authorize tokens against an authority, and it doesn't really provide the "centralized authentication structure", you will have to handle alot of the flow setup your self. generally just a watered down version of IS4.
Pros: fast and simple way to secure an api to an already existing Authority.
Cons: Doesn't allow you to create a Authentication Server.
Summary
I'd say go with Cookie Sharing if you don't plan on securing native apps or js apps.
If you are setting up token based authentication read below.
Go with IdentityServer4 for long term flexible solution and if you have time to learn how to use it and set it up.
if you have an authority and don't mind doing a bit of setup go with JWT Middleware, this will be a bit more flexible than Cookie Sharing.
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)";
I am maintaining a public website (no authorization required) that uses web services over https to perform various operations. Most of the calls to the web services are invoked from javascript.
What has recently occurred to me is that a malicious hacker could, if he/she chose to, call the webservices directly in an attempt to play havoc with the system.
In reality, there is not much damage they could do, but in practice these things are difficult to predict.
Bearing in mind that the web service calls will be exposed in javascript code (which is available to the client) what is the best approach I could use to prevent unauthorized and/or malicious access to the web services.
Sadly, I can't just restrict access by IP, as there are windows forms-based client applications out there which also interact with the web services.
Using windows authentication may be difficult, as these client apps can be run from anywhere in the world and the users are not part of any specific AD Group - or even domain for that matter.
I'd appreciate any suggestions, bearing in mind the two different classes of access and the exposure of the javascript code.
Anything called by javascript can be mimicked easily by a malicious user who has the right to use that javascript. I would suggest modifying the page to use a more server-side solution. Leave AJAX to stuff that can't be easily exploited.
Preventing an unauthorized user is MUCH easier than supporting full public access. If you drop a time-expiring guid on the user's cookies, tied to the individual user, that gets sent as one of the arguments to the Web Service, you have an extra, generally difficult-to-break, layer to the application.
Anyone who has access to execute the javascript, though, should have no trouble piecing it together. Someone who has no access to the javascript can probably be kept from accessing the Web Service easily.
It takes a bit of doing, but if your page is also ASP.net you can set up a shared session, turn on the EnableSession attribute on your webservice and use session data to secure the session. An overview can be found here: http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/ASPNET/sharing-asp-net-session-state-between-we
This would necessitate a different "version" of the service for your windows apps to consume.
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.