I have a web app protected by ASP.NET Forms Authentication. The site uses jQuery's $.ajax() functionality to call a web service in the same app.
Browsing to the web service .asmx does cause forms authentication to kick in and I once authenticated and make a $.ajax() call to the server I also see the ASP.NET session cookie and forms auth cookie being posted back to the server in Fiddler.
So...although all appears to be well, I'd like to put my mind at rest that indeed the web service will be protected by ASP.NET forms authentication when called from any of the pages in the web app using $.ajax().
From the server's perspective, an ajax request is not very different from normal GET/POST request - just some extra headers added on in the request. It passes through your normal authentication routine, the same as any other request - if that was not the case, you should be much more worried about the overall security of your application as requests can be forged very easily by people who know what they are doing.
You can easily setup a test to see if a resource requiring authentication successfully blocks out unauthorized requests arriving by Ajax. That should put your mind at ease.
As long as your checking on the server that the user is authenticated then yes you should be protected. I am using $ajax to call both PageMethods and to call an ASP.Net WCF service, and things look good.
It'll be protected, but watch out for what happens when your auth expires and the forms auth redirects back to the login url with a 302 FOUND response.
Related
I have an asp.net webforms solution that uses Identity for authentication. Within the solution I have some webservices that handle ajax requests for the site. The controller apis require authentication, which is not a problem from within the solution, since they receive auth cookie from the session. (Or atleast that's how I understood it).
Question is how do I handle authentication when calling the webservice outside the solution, for example from an android app or an outside web page etc?
The calling user should be authenticated, so that only user-relevant data can be accessed.
I am using AngularJS with ASP.NET Web Api server side. Seems to me like authentication has now become a breeze? Or is this too good to be true?
So I'm thinking of using the Web Api's "Individual User Accounts" authentication. And I am thinking that is all I need. As long as every request is authenticated and noone can get any data they shouldn't I shouldn't need to do much more right?
Or am I missing some key security fundamentals?
When it comes to securing the API you have two main approaches
Cookie based approach. This is the traditional way, where you use the standard form to authenticate the user and then set the form authentication cookie. All unauthorized request take the user to login page. If your API is always supported by UI front end to do login this method with work.
Second is using the authorization token in the header of the request. Once the user is authenticated he get a auth token, which he has to attach to every subsequent request in the Authorize HTTP header. Learn more about it here Individual Accounts in ASP.NET Web API . The advantage here is that you can expose your API without requiring a login page.
But remember when using the second approach, the auth token has to be stored on the client side as all subsequent request require this token. Look at this blog post Cookies vs Tokens. Getting auth right with Angular.JS to understand how to work with token.
Hope it helps.
Here's a great article about using Angular JS with WebAPI 2.0 token based authentication.
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
What approach is recommended in a case where I will be using ASP.NET MVC for authorization, but I will also have a few web services (WCF) that will be hit by JQuery AJAX requests once the user has been authorized.
I understand authorization in ASP.NET and in MVC. It's straightforward. One thing that I don't completely grasp is how my JQuery Ajax requests will become part of that session with the WCF services. In JQuery Ajax, do I need to manually attach a client side authentication token in the header of the request? Assuming this will be the same token returned from ASP.NET in the response header once the user is authorized?
Any tips on helping me understand how this works?
I have a bunch of websites that are setup identically to use a WIF identity provider. I've recently moved the business logic out of the web applications and into a Web Api service application. This runs in a different virtual directory to the other sites. The idea being that browser will put the data into the page AJAXy.
The issue I have is with securing the web API. It seems that WIF single sign-on works okay with traditional sites. The user can access one website, get redirected to the identity provider, login and get redirected back to the website they wanted. When they access another site they also get redirected back to the identity provider but needn't log in as a FEDAUTH cookie exists so they automatically get authenticated and redirected to the second site.
This doesn't work for the Web Api scenario because when the browser perhaps makes a GET to it, the Api will return a redirect to the calling javascript when it should be expecting JSON.
Is it even possible to secure Web Api with WIF?
Not sure whether I got you right, but it seems like the main problem is that javascript/ajax does not support http redirects.
A possible solution could be to simulate the redirection with a sequence of seperate calls in ajax:
Check whether you are authenticated on your web api site (by a dummy ajax call).
If this is not the case:
Call your sts over ajax and grab the security token out of the "wresult" form field.
Call the login site on your web api site and pass the security token as "wresult" data.
Dominick Bayer wrote a few blog posts about securing rest services. For further reading have a look at http://www.leastprivilege.com/. (Especially http://leastprivilege.com/2009/09/11/adding-a-rest-endpoint-to-a-wif-token-service/ and
http://leastprivilege.com/2010/05/05/thinktecture-identitymodel-wif-support-for-wcf-rest-services-and-odata/).
The following presentation from TechDays might also be interesting: http://www.microsoft.com/showcase/sv/se/details/ffc61019-9756-4175-adf4-7bdbc6dee400 (starting at about ~ 30 minutes).
Here's the situation, I've got a console application that needs to run once a day and make a few requests to pages that require authentication to view. The pages are hosted in a really basic ASP.Net Web Application.
So, I know that in order for the requests to go through successfully I have to authenticate with the server. So I've hooked up the console application to the ASP.Net Membership Provider I'm using for the web app and it successfully determines if a set of a credentials are valid. However, after calling Membership.ValidateUser() any requests I make just get the login screen. After doing some reading it seems that this is because I'm missing the important cookie information that persists my login or what-have-you.
I'm using a basic WebClient to make the requests and then reading/discarding the result.
So the meat of the question is this: Is there a simple way to validate the login information and hold on to it so that I can make the requests successfully, or is this the exact same case as the other two questions I found that require the WebClient to make a "manual" login request to the login.aspx page and try to hold on to the cookie from there?
The questions I'm referencing are:
Authenticating ASP.NET MVC user from a WPF application
and
Login to website and use cookie to get source for another page
With FormsAuthentication the webserver has to generate a Forms Authentication Ticket for you. The best (only?) way to do this is to log into the site, so I'd just log in like the other questions.
If the intent is to send data to the server and/or get data from the server, then the most logical architecture is probably to create a web service using either ASMX or WCF. Then configure the service to use a security token, such as a username token or a SAML token. This will make the client less likely to break when the server code changes its data model.
Otherwise, if you wish to use only a basic WebClient, then you will have to find a way to pass your credentials to the login page and retain the login cookie that is returned from the login request. Then, make sure that the login cookie is included on all subsequent requets, similar to the Stack Overflow question that you referenced, "Login to website and use cookie to get source for another page".