Where and when is the HttpContext.Current.User read from the HttpContext.Current.Request.Cookies ?
I have started looking at the ASP.NET MVC 5 source code http://aspnetwebstack.codeplex.com/ and couldn't figure out where principal was first set.
If you are using federated authentication, it is the SessionAuthenticationModule that uses its configured CookieHandler to deserialize a cookie into a SessionSecurityToken. It then uses the token to create a ClaimsPrincipal for the user. This ClaimsPrincipal is then used to set to the Thread.CurrentPrincipal and HttpContext.User properties. This process takes place in the AuthenticateRequest and PostAuthenticateRequest steps of the ASP.NET pipeline. Since it is done in the ASP.NET pipeline, I doubt you will find it in the MVC source code.
You can find more info on the SessionAuthenticationModule here on MSDN.
This is a great post on FormsAuth and FedAuth. It explains how all the bits fit together in the ASP.NET pipeline.
I am looking in the wrong spot. Authentication is now using the OWIN middleware. This blog is useful. The source code is in a project called katana. The source code is here. And here is the official asp.net blog post
In short. Owins is new way of processing the http request. The owins request is passed down a pipeline of 'middle ware' which handles the request. The CookieAuthenticationMiddleware from project katana (above) is responsible for decoding the authentication cookie.
Related
I have noticed that in classic ASP.NET MVC there is an Unvalidated property on Request which allows Access to raw values provided by the current request.
I cannot identify this property on ASP.NET MVC Core. Is there still a way to Access that information?
ASP.NET Core doesn't have the same request validation feature as it was in ASP.NET. Here are team responses in GH issue:
RequestValidation was always rather porous, and eventually we came to the realisation that validate should be an app concern, because what's validate for one application isn't valid for another,
and
We have no plans to ever build a request validation middleware like what existed in System.Web.
Also useful: SO Enable asp.net core request validation. If shortly, Model validation should be used instead.
I'm confused on how the Web API implements the authentication?
I have gone through the links 1.
Link1
Link2
and need to summarize what I understood.
Owin katana is a mechanism that can be implemented for authorization.
There will be Iprincipal which can be created either in the host or
in the httpmodule which will be attached to the currentthread to
validate.
Token based authentication implements owin.
I have very little idea about the authentication mechanism in web api. If someone can help me to understand this, It would be great.
I have the following doubts.
Owin is a new way of authentication in MVC? or its already exists as
a part of windows and form based authentication?
If I wrote a module to authenticate what are the different ways I can use to authenticate an api method/controller?
The answer to your question could be quite big, I will try to give you some guidelines:
Katana is Microsoft's implementation of the OWIN standard
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
Token based authorization is supported by OWIN and , therefore, by Katana.
There are two very usual ways to implement this token authorization, you can use Windows Authorization
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/enabling-windows-authentication-in-katana
or you can use a more standard and recommendable way using OAuth:
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
With ASP.net (netfx, not core), you use attributes on controller level to provide the metadata necessary to implement the authorization and authentication.
I understand what OWIN is, and it is good, and generally that Katana is a Microsoft implementation the standard in terms of the ASP.NET ecosystem.
I've also read that Katana has only so far been designed to work with WebApi and SignalR, since these take no dependency System.Web. Cool.
However, a new ASP.NET MVC 5 project template does include some Katana stuff and references Microsoft.Owin.Host.SystemWeb and that's where I get confused.
"[SystemWeb] provides an OWIN server that runs in the ASP.NET request pipeline"
http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
So, on IIS, does a request off the wire flow through the Owin pipeline before being routed to a WebApi action? And MVC actions, too? At what point in the pipeline does Owin sit?
Look at the following code from ChallengeResult.cs the template:
public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
{
Request.GetOwinContext().Authentication.Challenge(LoginProvider);
HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
response.RequestMessage = Request;
return Task.FromResult(response);
}
This appears to be talking to two pipelines; it tells the authentication middleware on the Owin pipeline to send a 401 challenge and then also returns a 401 via the normal response messaging system.
I'm sure its simple, but I'm confused.
When you use Owin.Host.SystemWeb, you are injecting in the usual HttpModules pipeline an HttpModule meant to host the OWIN pipeline.
From the IIS/ASP.NET perspective, the OWIN pipeline will be executed in that context.
If you want to exercise finer control on what runs when, you can add specific stage markers that map to the traditional event sequence.
I recommend Prabu's article at:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline
It gives a very nice overview of the process.
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.
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.