May be my question is crazy.
1) ASP.net MVC is stateless, so there is no session involved in here.
How does the authentication module work and do you have any articles which you can point me to understand the Authentication basics.
What are the authentication information stored in.
[Novice MVC]
The web is stateless. Both ASP.NET and ASP.NET MVC have mechanisms for creating an application state. Advocates of MVC like that it provides the developer with more control over how state is managed and how requests affect the managed state than Web Forms. Web Forms encapsulates state with ViewState which is not part of MVC. The MVC pattern allows you to control every action (including managing the application state) on a much more granular level. This is probably where you got the idea that MVC is stateless.
As a side note, you should favor using the TempDataDictionary over HttpSessionState for storing state-related data, because the default implementation the TempDataProvider is a wrapper of the HttpSessionState). The pattern is a little different but a good article can be found at http://www.gregshackles.com/2010/07/asp-net-mvc-do-you-know-where-your-tempdata-is/
ASP.NET (and MVC) authentication usually works by leveraging Forms Authentication. It can be configured in your web.config. ASP.NET Authentication Configuration.
If your client's browser supports cookies, the default behavior is for your authentication ticket to be stored in a cookie.
Who told you ASP.net MVC was stateless? In any case, authentication info is usually stored in an encrypted cookie. It's exactly the same as webforms in this regard.
UPDATE
Regarding ASP.NET MVC, see here for plenty to get you started: http://www.asp.net/mvc
For ASP.NET forms authentication, see MSDN
Technically, you could go stateless if you sent HTTP header authorization with every request.
Related
I have an application ASP.NET Core 2.1 and I want to create a cookie like a cookie created by FormsAuthentication.SetAuthCookie of ASP.NET MVC 4.5. Is It possible?
In the MVC I have this:
// some data put into Session like this, Session("FirstName") = objUser.FirstName
FormsAuthentication.SetAuthCookie(objUser.UserName, False)
What you're asking isn't strictly possible. Even if you could get the two cookies to look the same, they'd be encrypted differently, such that one site wouldn't be able to read the cookie set by another.
That said, the ability does technically exist to share cookies between ASP.NET Core and ASP.NET MVC. However, it requires the ASP.NET MVC project to switch to using the Data Protection API, versus the old-school machineKey encryption. The ASP.NET Core docs have more information.
Even with that, though, it's not going to work with FormsAuth (which uses ASP.NET Membership). You'd need to also update your MVC project to utilize ASP.NET Identity. Again, consult the documentation.
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.
We're building a Windows-authenticated ASP.NET MVC app. This will then call into an ASP.NET WebAPI layer sat on a different server.
We don't have Kerberos enabled so assume authentication with this will be via some form of Basic auth. We're also looking to use ASP.NET Membership/Identity for role management. All communication with the Membership database will be via the WebAPI.
Can anyone give guidance on how best to handle issuing authentication tokens for communication between the MVC and WebAPI apps, and how Authorize attributes may be used across both layers?
I've blogged detailed series of posts about Token based authentication in Web API using ASP.NET Identity, it should answer part of your questions, check it here
I started a new MVC5 project and am implementing forms authentication (which I used to do using custom code to check the user credentials and the FormsAuthentication object to login and logoff).
Now I've read that the identity model has changed, but I saw this line of code in the generated code:
private IAuthenticationManager AuthenticationManager
{
get
{
return HttpContext.GetOwinContext().Authentication;
}
}
Because later on the login is done on that object
( AuthenticationManager.SignIn)
I want to make sure I've got the right object.
I've read that OWIN is about decoupling ASP.NET from IIS, so I'm not sure why I need this GetOwinContext, because I am not using OWIN (at least I think)?
ASP.NET MVC 5 is using regular IIS Integrated Pipeline to operate which involves a lot of steps such as AuthenticateRequest, PostAuthenticateRequests and so on. FormsAuthenticationModule is responsible for management of Forms Authentication process which involves decryption / extracting user information from cookie and it is integrated in several of those steps.
Now, when it comes to part with OWIN, it is operating on the completely different approach, which will be the only approach in the nearby future, so you might consider dropping Forms authentication completely because at this point, there are several better ways to implement your security.
If you go with IIS Integrated Pipeline and want to skip all the OWIN thing (which I strongly recommend against), you might check classes ClaimsAuthenticationManager, ClaimsAuthorizationManager and SessionAuthenticationModule. These effectively replace RoleManagerModule and FormsAuthenticationModule in order to allow Claims-Based Access Control, which is based on concept of Claims, which again in turn are used for all modern authentication protocols such as WS-Federation, OAuth2, etc.
Back to OWIN part - OWIN has it's own pipeline, which with usage of some "bridge" assemblies can hook up on IIS events as well, meaning that you have OWIN web server running in the background (Microsoft.Owin.SystemWeb) and also System.Web that is leveraging IIS for MVC purposes.
So when you use OWIN authentication in MVC 5, you're basically still using IIS Integrating Pipeline for MVC, but you're using OWIN middleware for security, which is part of OWIN pipeline.
Now in order to access that OWIN pipeline, you need to do GetOwinContext. OwinContext is OWIN version of previously used HttpContext, except on the base level it is quite different. OWIN middleware operates exclusively on OwinContext (IOwinContext), so to use middleware you need to access the context, since context has information that is required by the middleware.
This is unfortunately quite complex, but I would strongly suggest to you to start reading about OWIN and Katana, and pay attention on vNext as well, as Forms Authentication is right now pretty much obsolete, and will definitely stop being supported with vNext so you might start building an application now that will require a lot of refactoring later.
We are going to start a new solution for both "desktop/mobile responsive web site" and "mobile app". Both projects (web site and mobile app) need to access same business/data layer.
The tier structure for web site is going to be something like the following:
Browser -> ASP.NET MVC Web Site -> Business Layer -> Data Layer -> Database
The tier structure for mobile app is going to be as follows:
Smart Device -> ASP.NET Web Api Service layer -> Business Layer -> Data Layer -> Database
We don't want web site to consume web api.
We also don't need to integrate with any social identity in our scenario. I heard that ASP.NET MVC discourages token approach for security (authentication and authorization) and encourages the cookie approach. However, consuming Web Api will be lot easier, if we employe token approach and cookies are obviously discouraged in REST services.
While we are fine to start with new ASP.NET Identity system, we are not quite sure on how to deal with both scenarios without rewriting and supporting code for both scenarios.
Based on the above grounds, how can we design a common security pattern which works for both of our scenarios i.e., ASP.NET MVC Web site and ASP.NET Web API.
If you self-host using OWIN, you can look at creating an OWIN middleware. If you web-host using IIS, you can create an Http module to authenticate and establish the identity by handling authenticate event. Http module can be written in such a way to look for a token and if not present, fall back to cookie. By cookie approach with MVC, I believe you mean Forms Authentication. With that, FormsAuthenticationModule comes into play. So, your module just need to be aware of this and play along nicely. Ultimately, identity is established on Http context and you can use Authorize attribute in both MVC and API controllers. Here is an example of how to create an Http module for authentication. Basic authentication is implemented here but you can modify it for tokens.