I feel like I might be going down the wrong route here, and was hoping someone would be able to do a little course correcting!
I'm creating a web app which uses Windows Authentication. However, I wish to assign custom claims/roles to specific windows users, which I'm planning on storing in a SQL database.
I thought a way to do this would be to enable Windows Authentication in the web.config of my app, but to add an AuthenticationManager from WIF which can add custom claims (which come directly from the database) to the principal/identity. Then an AuthorizationManager would handle authorization to specific controller actions.
The problems I'm having right now is that my Authentication and AuthorizationManagers aren't being called. I'm not sure what I'm missing (they're registered in the web.config), but I suspect maybe it's because I'm using Windows Authentication...? Additionally, my Authorize attributes aren't calling the AuthorizationManager, possibly because I need to create a new attribute.
Is this a viable route to go down, or should I be looking at creating a custom RoleProvider instead?
The ClaimsAuthenticationManager is not called automatically - the FAM calls it.
That said - you can call it yourself, e.g. in Post_AuthenticateRequest and then set a cookie using the SAM. Thats totally doable.
Related
How can I trigger some code right after authentication?
Let's say I want to give my application a single session constraint per user, for example. How can I implement it in ASP.Net Core 2.0?
Update:
Clarification, I want to trigger code right after a user is considered authenticated (after .net authentication middleware have validated the user is who claims to be). I have not mentioned Middleware before because there might be an easier way, like an event, to trigger some code. Maybe the proper question would be if is there such event/way, or if I should manage it through a custom Middleware attached right after Authentication?
The simplest scenario, is calling the method you want in any action in MVC controller. Actions are always called after authentication (I think this is not what you need, but the information your provided are very poor, as you did not mentioned exactly what do you mean by right after authentication).
The other possiblity (which is probably what you want), is to create a middleware, and add it to the pipeline exactly after authentication middleware. When you have your middleware in the pipeline, you can write to do what ever you want.
Middleware writing is well documented here:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware?tabs=aspnetcore2x
I'm fairly new to Web API and have an existing app that, by default, uses federated authentication.
However, I have one specific controller that I'd like to use either the default federated auth, or a second method that essentially uses a password sent in an HTTP header.
My initial Googling turned up stuff like this:
http://blogs.msdn.com/b/hongmeig1/archive/2012/02/27/supporting-multiple-authentication-schemes-with-web-api.aspx
...but the approach (using an HTTP module to set the HttpContext.User) seems to be universal to a site rather than targeted to a specific controller.
Plus, I'm wondering if there are more modern approaches available since the blog was written in 2012.
Can anyone help point me in the right direction?
EDIT: In further digging, it seems like I want to use an OverrideAuthenticationAttribute in conjunction with a custom authentication filter per:
What OverrideAuthenticationAttribute is for?
...but I'm trying to figure out the best way to do it (preserving default, while also adding an additional auth option).
I am looking for help creating a Web API with custom username/password authentication.
I have my own database to validate users against, I do not want to use windows authentication.
I am hoping to be able to decorate my web api calls with an attribute like [Authorize], so that calls made without logging in will fail.
I do not want to have to pass credentials as a parameter to every method.
This API is going to be consumed primarily by mobile devices using Xamarin PCL.
The web API must use SSL.
This seems like a simple setup yet my googling does not reveal any super useful hits.
Ideally I'd want a Login controller that authorizes a user and allows subsequent method calls through.
Can someone provide a basic example or some good reading material?
It's a big subject and you probably need to spend some time boning up on the basics, sorry.
That said...
In order for subsequent method calls to be authenticated, you need something that can be passed back with every request. If you are calling your api from a website, say because you are using Angular or similar, then a simple cookie (appropriately encrypted and MACed) will work. Exactly how to implement that depends on whether you are using OWIN or not and whether you also have MVC in your project to serve up your pages. Don't create the cookie yourself, use FormsAuthentication or the equivalent OWIN middleware.
You don't need to use Microsofts Membership or Identity, but be aware that doing your own password handling is not trivial and you really need to know what you are doing with that stuff - there is no substitute for a lot of research if you want to do that.
If you need to call the api from something other than a Web site, then a cookie is painful. Also be mindful that there are some subtle CSRF vulnerabilities when using cookies and Web api that you need to understand and protect against.
An alternative to cookies is to embed something like ThinkTecture Identityserver (it's free) and use that to issue oAuth tokens and then attach them to each API request. It has a number of advantages but is also more complex.
Resources
You did ask for pointers on where to start reading. Your task is complicated by the fact that Microsoft has been changing their "default" approach to it several times over the last few years. The current default approach is Identity which replaces the previous MembershipProvider (good riddance). If you are new to this, I'd suggest you go that route to be honest - you can extend it and it ties in with most of the rest of the stack very nicely. Yes, you lose some flexibility and you need to wrap it around your current user store. But you need to ask yourself if the security you get out of the box isn't worth that.
I would also recommend Brock Allen's blog. It's pretty hardcore but he knows his stuff and will often explain the innards of a lot of Microsoft authentication technologies.
I would recommend you try to read up on "OWIN Authentication Middleware". It's where it is all going, not least with ASP.Net vNext. Sadly, most of the documentation out there focus on how super easy it is to use (and it is - for a demo) but lack any in-depth info about how it really works, which can be very frustrating.
In order to get to grips with how tokens and the different standards work, I would recommend you watch this video here: http://www.ndcvideos.com/#/app/video/2651
Then look at Azure Mobile Services which has even got client-side libraries for handling the auth I believe or ThinkTecture Identity Server. Even if you end up not using IdSrv, by going through their tutorials on how to use it, you will learn an awful lot about how this whole thing works in general; it's all based on open standards. Docs here: http://identityserver.github.io/Documentation/docs/
Try working through their tutorials; They use a windows console app in place of an app, but the concept is the same.
I wish you luck but would like to just close by saying please don't just hack something together that seems to work. Web security is increasingly complex and it is very easy to leave vulnerabilities in your code - I talk from experience :)
Don't be a Moonpig.
Depending on which version you are using. MVC5 Web API 2 implements an approach called bearer tokens. So you basically execute a post with username and password upfront to your https://applicationhostlocation/token endpoint. This will return a bearer token in the payload. You send subsequent https requests to your authorized web api methods with the bearer token in a header. This is all out of the box with the latest version of the web api. This link outlines the approach pretty well: http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
Custom Membership Provider my friend!
https://codeutil.wordpress.com/2013/05/14/forms-authentication-in-asp-net-mvc-4/
With custom membership provider You can set a Authorization Cookie Token (aka AuthCookie), and use the Forms Authentication technology in your application. With a Custom Membership Provider, You'll be able to create a custom Validation Method that access your DataBase to match users credentials.
With the AuthCookie, every subsequent request will be authenticated, like a traditional Authorization Cookie technology.
Also, you can use a rewrite Url approach to enforce users to be redirected to the SSL pages: Best way in asp.net to force https for an entire site?
I have a project which uses both Web Api and MVC. The authentication is handled by FormsAuthentication, which creates a cookie containing some data regarding the user.
I have extended System.Web.Mvc.AuthorizeAttribute and added it to every MVC controller. What it does is extend AuthorizeCore and check to content of the cookie, which is my own extension of IPrinciple, for wether the user currently has limited access.
I would like to do a similar check for calls to my Web Api, so i have made an extension for System.Web.Http.AuthorizeAttribute which overrides the IsAuthorized method.
In this method i would like to make the same check as for the controller, but i don't know how to get the information from the cookie or if this is even the proper way to do this.
In general using cookie authentication in web api is not recommended.
The reason is that cookies are handled well only in browsers The whole concept of web api is to allow other clients (native clients, java script ...) to use it as well.
If you sure that your server is going to be accessed from browser only maybe you should move your api actions to MVC project (it could return json / xml as well). This way you will not have to deal with those kind of issues.
For web api I would recommend using token based authentication
I want to control access to certain pages of my app by cookie. But I want to coordinate this from only one place. I thought put a check in a Layout.cshtml I.E. That way all pages use this Layout will do automatically. Is that good?
Edit: Security for this app its not a concern.
You're violating one of the core principles of MVC – never put real logic in a view.
Instead, you should create an ActionFilter.
You should also figure out how to secure the cookie; you should probably use ASP.Net's existing membership system
No, it's not good because cookies can be manipulated easily by anyone.
Why don't you want to use the normal Authentication and Authorization techniques that are already available?
Using cookies for controlling access to pages does NOT sound like a good idea. You will have to create a way to secure the cookie, which isn't easy. Without that, your authentication will be easy to spoof.
I would recommend that you use the built in authentication and authorization mechanisms for MVC 4, which is well tested and built for this purpose. Here is one article to get you started.
Using the [Authorize] and [AllowAnonymous] attributes of MVC4, you can be quite flexible when restricting parts of your site to authorized users.
I've posted a more lengthy example using above mentioned attributes as an answer to another SO question.
you should use the Authorize attribute on your controllers/pages instead of cookies
and restrict the pages to certain roles and assign users to roles.