I have a C# MVC 5 website that will be called from a legacy 3.5 asp.net application that has performed all the pre-authentication of users. The idea is that the legacy app will generate a "token" (guid) with a matching database entry containing all relevant user information. The token will be passed to the MVC site via the url.
The MVC application needs to authenticate the user via the token received in the querystring and validate via the same database entry (the token will only remain valid for a very short period - say 60 seconds) with that expiry being stipulated and controlled at the database. Once the user is authenticated the user access should be maintained for a given time. I am open to using readonly session state and having access for life of the session or alternatively open to suggestions for handling expiry some other way.
I'm not particularly well versed in aspects of security for .NET having only really used "standard" forms authentication in .NET ASP and even less familiar with MVC.
The closest thing I've found to this concept is the below thread however there is simply not enough detail in the solution for someone with my lack of knowledge / experience to implement, also it's fairly old so may be outdated?
Authenticating users with auth token in query string with ASP.NET MVC
Related
My team currently uses WebForms for projects, but I'm trying to convince everyone to switch to MVC. One of the problems that I'm running into is with authentication. I can't figure how to to implement our login process to work with MVC.
Our authentication is done via mostly a web service (we pass username & password and are told if it is valid or not), but occasionally we use ActiveDirectory for logins.
Right now we are using sessionstate to store information about the logged in person. How would I translate this to ASP.NET MVC? I've read a lot about various things -- Claims, Roles, MembershipProvider, IProvider, ASP.NET Identity, OWIN, but ASP.NET has been evolving so rapidly that I'm afraid that I'm reading old information on StackOverflow.
Right now we are using sessionstate to store information about the logged in person.
Don't do this. Ever. Not in WebForms, or MVC. It's highly insecure and easily spoofed. Session should never be used for anything to do with Authentication or Authorization. Plus, Sessionstate is volatile, and IIS can dump your session at any time, losing synchronization with your authentication.
The solution to your problem is very simple. You already have the authentication in your web service (though I question whether this would be secure either, given your Sessionstate authentication methods, but that's a different argument). All you need is the Authentication portion, which is easily provided by FormsAuthentication to set the cookie to allow logins.
You Validate against your service, if you succeed, you call FormsAuthentication.SetCookie(), and then you add [Authorize] to all the MVC action methods you want to protect. It's really that simple.
If you need to have information available about the user, then you would create a custom IIdentity and/or IPrincipal implementation that provides that information, making it secure (secured by encrypted cookie) and easy to access.
I'm re-developing an app as a web app (the "previous" iteration was in VB6) to run on azure. One requirement is that we only use facebook/google authentication (OAuth 2.0). Another business requirement lead me to break my project into the following schema:
1 Project for the WebAPI 2.0
1 Project for Controllers
1 for Data Access (typical layer pattern)
N Projects for MVC 5 front-end
The idea is that the MVC projects will only consume the WebAPI via javascript/json! The N MVC projects will contain just the GET implementation for the pages. No models or others actions (post for example). In other words the MVC projects are completally disconnectd from the other projects and should have no intelligence what-so-ever!
This is the selected way because of (bitchy clients and) limited time constraints.
Anyway, as you can notice the "core" (WebAPI + controllers + DA) is shared. The core is in fact a multi-tenant service. (but remember the disconnected facet!)
My problem here is: How do I handle Authorization? What/how should treat the passing of the claims between the MVC projects and the WebAPI? Im lost here. After some thought, I came to the conclusion that I need to make the WebAPI project act as a proxy here, something like:
Random users lands on www.myClientWebsite.com/Register
Chooses a login provider
The MVC project redirects the user signaling facebook to return to www.myWebAPI.com/Register
I intercept the claim and redirect the user to the original www.myClientWebsite.com/LoginComplete or something...
Am I getting it wrong?
You have to use OAuth 2 for authentication and authorization purpose in this scenario. Yes, you should be making the authentication at the MVC level and then use tokens to keep the security intact for rest calls.
Here your MVC application should get a Bearer token from the identity provider like google and then hide it some where on the form. Then for every jquery request you make to web api, you have to send this bearer token in the request.
[Update]
This is considered kind of hack and I do not encourage it. And this works only if both the systems are in same domain.
[\Update]
If both MVC and Web API are on different domains, then you can think of using Azure ACS Service Identity to build the trust between domains. Then pass the bearer token of User claims in the payload of the request.
[Update]
This is much more better way to handle this but must be accompanied with proper token revocation and https security.
[\Update]
I have a single page app that uses a standard Controller (not ApiController) for retrieving all HTML views, which is done via ajax. However, WebApi is utilized using breezejs for the client to talk to the backend database. I am implementing ASP.NET identity security - should I use MVC cookie authentication or bearer token? I need the solution to illustrate a separate login page, and need a clean server side redirect.
Disclaimer
This is a relatively trivial question because it is very specific and by understanding the difference in authentication between Web API and MVC Controllers this should be fairly straight forward.
Assumptions
Your Web API Project has it's own authentication and does not talk to the MVC project to get a session user or anything
Your ASP.NET MVC Controllers are in a project using forms authentication and storing the user in a session cookie.
When I reference MVC below you undertand these are referencing ASP.NET MVC
Recommendation
What I would do is have your MVC project use OAuth for authentication and store the user in a cookie in the session that you can set and get. Then your controller actions that serve views can be decorated with the Authorize attribute. This will redirect users to the login page when they try to access a view they are not allowed to (as long as that is set up in your web.config
For the Web API Project you can't rely on Session because it sounds like you are decoupling the two projects. This is my recommendation -
When your user is successfully authenticated in your MVC Project make a request to the Web API to an open log in method. This would do some logical test and then either store the user in the DB with a session token of some sort or automatically write the user to the DB.
Now your user that is stored in session in your MVC project you can pass that down to the client and append it to the Breeze calls to your Web API and use that for authentication. You will need to explicitly set up how long that token is for and such but it is pretty easy to append this to the Breeze.js call like such -
var query = breeze.EntityQuery.from('myService').withParameters({'tokenId': thisTokenId});
Now your queries will hit the API with a tokenId parameter that it can use for authentication.
Edit
If you want to set up your ASP.NET MVC Project to use OAuth you can following along with this link -
http://www.asp.net/mvc/tutorials/security/using-oauth-providers-with-mvc
Remember that forms based authentication just means (in a nutshell) that you will provide the user some way of logging in with a form of some sort.
I have successfully login to Web Api and I have received "accessToken".
Now I need to use that accessToken numerous times to call that public WebApi.
Where is the best place to store that accessToken in ASP.NET MVC4 application ?
What if I store accessToken to session?
What if I store accessToken to userData in FormsAuthenticationTicket?
APS.NET Session is stored on the server so this is best in terms of security. The user data portion of the forms authentication ticket is also a good place. Forms authentication automatically encrypts the ticket so you should be fine as well. The advantage of the forms authentication cookie is that you don't need to worry about distributed environments. For example if you run in a web farm you will have to use an out-of-proc session state whereas the cookie is on the client. It's really up to you. Both solutions are good enough.
I have reviewed some of the similar questions on this site but could not find one with an answer appropriate for my situation.
I am using asp.net mvc, and it is communicating securely with stateless wcf services. for each service call, i need to pass in the username and a few other ints for identification purposes. - not password, the services are not authenticating.
I am using forms auth to authenticate the users. I am just not sure where, after the user logs in, I should store their username and other account details used for the scope of the user's time logged into the site. suggestions for webforms apps include in "Session". Is there an equivilent alternative in MVC? is storing the info in the forms auth cookie the best solution? it seems like it would be slow to have that info in a cookie as opposed to somewhere else in memory..
thanks
If you need access to a select few bits of information about the current user over and over again, you could combine FormsAuthentication with a custom principal implementation.
The Forms authentication mechanism will write a cookie to your client's disk, and will recreate the custom principal based on that cookie for each call. You could e.g. store something like a user "level", a user "profile" or other small chunks of information, which would then be accessible through the HttpContext.Current.User at any time during the lifetime of your request.
Check out these resources on the topic:
MSDN docs on How to Create a Custom Principal Identity
Using Custom Principal with Forms Authentication in ASP.NET
and I'm sure googling or binging for "ASP.NET custom principal" will render quite a few more hits for you!
yes, unless it's a lot of information, the preferred location is to store it in the cookie. Aside from that, session is the next best place.