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.
Related
I have 2 web applications, one is ASP.NET MVC 5 + WIF hosted in IIS, another is a web service based on WCF and self-hosted. Both of them are under same domain (so there are no security issues to change cookie format) and referring to the same STS (in same security realm), so theoretically if one user already authenticated, he should be able to access other entities within same security realm without authentication.
However, these 2 websites are using different session token format. For ASP.NET MVC 5 project, it uses WIF implemented standard security session token and serialized to cookie; for WCF web service, it uses its own token/cookie format.
Then we have a problem.
When user navigates from ASP.NET MVC website to WCF web service, because WCF web service cannot recognize WIF session token (FedAuth and FedAuth1), so it redirects user to STS and login again, that is not the biggest problem, the biggest problem is, after use logged in, and POST raw SAML2 token back to WCF web service, WCF web service creates its own format token and tries to set client cookie, it actually doesn't work, I guess maybe there are already FedAuth and FedAuth1 cookie in header so header cannot accommodate more tokens (4K limit?)? Having thought about this for a while, there are are several solutions come into my mind:
Unifying token format. I need to subclass SecurityTokenHandler (maybe also need to subclass CookieHandler), use the same token format that WCF service uses, so when jumps to WCF web service, it can recognize the session token. That needs to dig deep into FAM and SAM.
Force re-login. I can clear FedAuth and FedAuth1 cookies before navigates to WCF web service, it is acceptable that user needs to login again, this is a short term fix, but how can I capture this navigation away event and clear cookie? The only way I think I can do is before I change window.location.href, use jQuery.cookie to clear cookie, I am not sure if it is the correct way, this is my first question.
Adding a cookie translation layer between ASP.NET and WCF, use WIF session token in ASP.NET website, and when jumps to WCF web service, change the token format. But for this solution I don't know how to capture the jump action and how can I get raw SAML2 token? May be I can save it in WSFederationAuthenticationModule_SecurityTokenReceived event handler? But how to deal with multi tokens from multi users and multi sessions?
Are there other better suggestions?
I work on an application where I have a separate MVC layer and Web API Layer, both have the same authentication mechanism, I have chosen the individual accounts authentication option while adding the projects. The web api service layer will be directly accessed by some other mobile clients also.
But when the user logs in through MVC he should be able to access Web Api seamlessly, but I don’t want to really pass the username and password from MVC to the Web Api layer, I am told it is a bad practice. but i need to authenticate and authorize my user, so the only option i have thought of is to have a default account at Web API level to issue tokens, and this will be called from MVC post the authentication and a token will be returned which is written to a cookie in the client. Now the Ajax calls from the UI can use this bearer token and get the job done.
The only glitch I have here is that, because I am using a default account I need user details again for authorization at service level, though I am doing authorization at my UI level, the user can spoof the system. I was lost here and came up with a solution like, when the user logs in to MVC will send across user details also along with the call to get the WebAPI token and issue another token to the user so that the user uses both of the tokens to make a call to web api from MVC.
I am not sure if this works or if it is even the best way. I just wanted to check, how I should go from here. Any help on this will be really great.
This is a really good example of integration - I know they use Angular as the client but you can learn from this:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Check this section to see how they decouple the API from the front end (Part of the same article).
http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/
I have built a SPA application with Hot Towel (durandal) and I have problems to understand the authentication.
When I am loading data from my database how can I filter this data to the current logged in userid ?
thanks for help,
Best Reguards
If your SPA is calling asp.net of any kind on the back end you can still use Forms Auth cookies to secure your ajax endpoints and identify the user making the request. Depending on how SPA like you need it you can just use a standard aspx or mvc login page, then from there redirect the user to your SPA start page that calls your main.js and starts your SPA. All ajax calls you make to that site will have the Forms Auth cookie set and you can use it to verify the user making the request. Here is a link to standard forms auth. If you want handle the login process in durandal as well that can still be done, you just need to make your ajax endpoints for logging in and out to allow anonymous and then handle setting the forms auth cookie in them.
On the server-side, referencing User.Identity in the controller will get you the properties of the currently authenticated user. The question is, what form of authentication does your application use (Windows, Forms, Basic, Anonymous, etc.)?
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".
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.