I'm developing a rich client javascript application with ASP MVC 4 Web API back end.
How would you suggest to secure all the ajax requests ad make sure they are made from an authenticated user.
Thanks !
Any securing mechanism would do, consider for example Forms authentication.
You add the Authorize attribute to your controller methods and ajax requests carry the cookie if it has been issued from the server.
This is really as simple. If for some reason it doesn't apply to your scenario, you'd have to be more specific.
As Wiktor suggested, you could use Form-based authentication (HTTP mechanism).
If we consider your question more broadly though, what does it mean to secure all the AJAX requests?
You probably want to achieve:
integrity
confidentiality
non repudiation
accountability
more?
The topic is more broadly discussed on wikipedia. More specifically you want to do the following in your API:
secure the communication channel: use SSL (either one-way or 2-way). This will provide integrity and confidentiality
use authentication. This will give you non-repudiation and accountability. There are different authentication methods available in .NET (Forms, HTTP Basic, SAML-based...)
for advanced scenarios around authorization (which user is allowed to call with method), use claims-based authorization (part of .NET framework), RBAC, or XACML.
Related
At the moment we are building a web shop as a SPA application. All the SKU information is provided by a Web Api 2 service.
Of course the web shop is publicly available to every visitor, and currently there is only one user who can log in to manage the web shop: the administrator.
For the administrator we built in the basic authentication with the bearer token, as a lot of samples on the internet shows us, but now we need every user to log in before they can see any product. Not really what we have in mind for a web shop ;-)
What we would like to implement is that our Web Api is not available to the world but only for our SPA application. Every blog post or tutorial on authorization seems to assume that there is always a user that needs to log in, in our case there is only one user: the administrator.
The AllowAnonymous attribute makes specific API calls available to the world again, so that's also a dead end.
Basically it comes down to preventing any other apps (web or mobile) to fetch the data from our Web Api.
What would be the best and most secure approach to secure our Web Api without having the anonymous visitors of our web shop to log in?
Solution for now: Altough I'm not 100% happy with this solution, it will work for now. We implemented the OAuth Implicit flow with CORS enabled for specific domain.
You should take a look at the OAuth 2.0 client credentials flow. The client in OAuth speak is the application and not the user using the application. This way you can make sure only your SPA app can access the backend API.
The parts that only should allow access to the administrator, you can decorate with the [Authorize(roles = administrator)] attribute, which prevents any other roles from having access.
I think Json Web Token could help you with this. This article has more information about using Json Web Token for granular authorization of your web api.
OAuth 2.0 is inherently insecure, and solely relies upon SSL. It has no encryption, and most of the latest web api gurus are suggesting that it's dead. This again is relative to what you need the security for. If it's for a social SPA where the data isn't financial or medical, for example, and good enough SSL security is ok, then perhaps OpenID or OAuth2 is suitable.
A much better solution is to implement Identity 2.0 for the Web API authentication flow, and then utilize something like Hawk Protocol for HTTP MAC implementation. Check this out : https://github.com/webapibook/hawknet for an example.
For OAuth2 framework and a extensible solution, check out Thinktecture.IdentityServer3 on GitHub
For a lightweight .net 4.5 Web API Tokenization solution, check out Thinktecture.IdentityServer2 on GitHub.
Hope it helps.
What is the simplest security that could be applied in ASP.NET Web API in MVC 4 to prevent external users from accessing the Web service , is there anything simple enough like authorization of some token which could be maintained for each instance?
It depends, a Http Web API is stateless by nature. If you are invoking the Web API from a web browser using Ajax, you might rely on cookies for maintaining the user identity in the session. Otherwise, other traditional HTTP authentication mechanisms like basic authentication requires the user credentials in every call. You might want to take at the Thinktecture.IdentityModel library, which provides a lot of extensibility points for authentication.
http://leastprivilege.com/2012/10/23/mixing-mvc-forms-authentication-and-web-api-basic-authentication/
Regarding authorization. The framework already ships with a few attributes like AllowAnonymousAttribute or AuthorizeAttribute that you can use to decorate the Web Api methods.
Better you could have search about Authorization in MVC. Yes it does support it. Please check the below links which could be helpful.
Secure MVC 4
Redirect unauthorized Users
Custom Authorize
Our current app is a standard spring 2.5 application with Form Based Authentication using Acegi. However, we need to expose some REST Service for 3rd party application and we are trying to use BASIC auth over SSL. We have used RESTEAsy for exposing the REST Services. Now, given that the rest of the application uses form & Session based authentication, how can I enable basic authentication for the few REST Services.
To me, the usecase seems normal, however, I couldn't find much reference on the web. Any comment/suggestions will be very much appreciated.
Regarding the more general question of whether to secure the REST service using Form authentication or Basic/Digest authentication - this is deeply tied into one of the more important constraints of RESTful architecture - statelessness.
With this in mind, logging into a service means keeping state on the server, which goes against the stateless server constraint. From an authentication POV, Form based authentication implies logging in, whereas Basic/Digest authentication means embedding the authentication credentials in each request, with no need to keep any state on the server. This is why this kind of authentication is much more inline with the way REST is meant to be build.
Hope this helps.
Check out Basic/Digest Authentication in the Spring Security Reference.
How can I be confident that only our silverlight applications are calling our azure services?
The silverlight client will need to have a user authenticated and have the correct permissions to perform an action but I did not know how application authenticity is commonly implemented on these azure service calls. I know you can sign the application (required for client updates). Is this combined with ssl connections enough? Should I be using a cert at the client?
What are some common approaches to this problem?
You can put data inside your message headers. You can do it in the SOAP header when using SOAP or in the HTTP header when using REST. Then when you've done this you can use a secure SSL channel to communicate so people can't sniff out your packages.
http://blogs.msdn.com/b/nathana/archive/2007/05/29/custom-soap-headers-wcf-and-asmx.aspx
When you're using RIA service and you want to add data in the HTTP header then see my blog:
http://strugglesofacoder.blogspot.com/2011/02/normal-0-21-false-false-false-nl-be-x.html
Silverlight does not have a way of identifying itself to the service, and even if it does, a little tool called Fiddler will expose all that information for anyone to exploit your services.
You should assume nothing about the client. Your services should perform validation on the incoming requests without trying to determine who/what the client is.
I do hope someone has a solution because I haven't found one yet, and I'd love to secure my services so that only Silverlight can make requests.
You could do this using the Access Control Service, there is a nice example on codeplex written by someone of the ACS team:
http://acs.codeplex.com/wikipage?title=ACS%20Windows%20Phone%20Sample&referringTitle=Samples
although it is a windows phone 7 client (which is also silverligh), i think you can distill what you need from it.
Silverlight is a tricky beast when it comes to integrating with ACS, it seems that writing to the headers from Silverlight to pass authentication information along is very tricky - there isn't an easy way to intercept the calls to wrap them with the auth header in Silverlight, like you could do in an ASP.NET application.
You can use ACS to get your identifying information to Silverlight by using an approach like this example: http://channel9.msdn.com/Events/MIX/MIX10/SVC01
What I ended up doing is wrapping some unique identifier claim in a SWT token, signed with a key that's known by both Silverlight and the web service, and having the web service verify that that user has access. By placing the unique identifier in a signed SWT token (with an expiration time of a very short amount - to help reduce attacks where folks copy a valid request and send it again at a later time), I could more comfortably believe that the request was truly coming from my Silverlight app.
To pass the token, I just made a class that contains all the parameters I want to pass (that way I didn't have to keep rewriting the function definitions), including the SWT token.
Hope this helps.
I'm interested to know what methods people use to secure their webservices from unauthorized web service consumers.
There is a protocol specifically for web services security WS-Security. I've used parts of it in the past but at the time there was not a lot of support for it in .Net so it was a lot of work.
Currently with .Net I use SOAP Extension Headers. I have one web service call to authenticate and get a session token and then include that token in a SOAP header for every subsequent call, somewhat similar to this example. Of course all the request must travel over TLS to keep them from being compromised.
I usually require either a user id/password to be sent each time, or return a token from the first authenticated connection that can be used subsequently.
Nothing fancy. Pretty similar to standard web app login.
I've used both SOAP headers and method parameters to pass user credentials -- .NET makes using the SOAP headers pretty easy, but I had issues with this using Java (several months back). I also do some IP-based filtering if the service is not intended for client (browser) use, but rather from backend web servers. Public, browser consumable web services are often protected by session cookies -- i.e, requires a valid logon to the web site, then the standard session authentication mechanism is used for requests via AJAX to web services.
You can use network appliances such as IBM's DataPower or Vordel if you don't want to handle in your own application.