I am building a web app in MVC 5 - but don't yet have a way to authenticate or authorize users.
I am using dapper.net for the repository layer.
I do not want to use ASP.NET Identity because it is too complex and tightly coupled to Entity Framework.
I want to use Cookies so users can remain logged in between visits - for months.
Basic Authentication doesn't support cookies and although I will be using SSL seems insecure.
Forms Authentication appears to be being deprecated.
I would like to use Authentication Filters / Attributes.
I just want a simple solution that lets me control how things work.
Is this possible? How can I go about this?
You can use Custom Authentication Filter in MVC
Related
I'm wondering if it is possible to use Thinktecture IdentityServer simply as an STS alongside an existing web app? That is, I want to use ASP.NET Identity for authentication in my web app because I want to use all of the built-in functionality like 2-factor, etc. However, I want to use IdentityServer as an STS to serve up tokens to access my web services (WCF and Web API).
I thought perhaps I need to authenticate normally through ASP.NET Identity, then again through IdentityServer to get the token. However, this seems heavy and wasteful.
Is there perhaps some way to authenticate against the IdentityServer directly from ASP.NET Identity? I saw the sample where we can integrate the two together (IdentityServer using ASP.NET Identity), but it seemed like I might lose the ability to use all of the built-in stuff like two-factor workflows.
I'm hoping I'm way off base here, and apologies if I have some fundamental misunderstandings about how IdentityServer works. Perhaps there is a way to get all of the added functionality that ASP.NET Identity provides from within IdentityServer?
Identity Server will handle all authentication, no need for double sign-ins if you are using it correctly.
You'll have to implement two factor authentication yourself though as it is not currently supported by Identity Server. However extending Identity Server's existing support for ASP.NET Identity to allow for two factor authentication is definately possible.
I think your first port of call should be to have a bit of a deep dive into the Identity Server documentation and the OpenID Connect protocol. After that check out UserService documentation and then derive from the existing ASP.NET Identity UserService to add support for two factor authentication.
I'm implement aspnet identity with my MVC5 project. I have configured my project to use cookie authentication, form authentication and external authentication (facebook and google). Everything work fine.
Now i have a requirement to log whenever user log in system and i need to do some further logic. For the form authentication and external authentication i have a controller action that i can add my logic. However for the case user just come back system via cookie, how do i handle it?
I'm sure there's a better way to handle this, but a basic method would be to track all activity by the user, and then use timestamps to determine when a user was last active on your site.
Discussed here: Track user activity/actions for an asp.net mvc website?
OnExecuting filters here: https://msdn.microsoft.com/en-us/library/gg416513%28VS.98%29.aspx
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 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'm new to the ASP.NET world. Since I want to use the ORM it seems I would want an Entity to represent the User or Member or whatever, not some data tucked away by the forms authentication api. In fact I don't see how I can live without one.
How do people deal with this? Roll your own authentication? Or is there a best practice for incorporating forms authentication with the Entity Framework?
In short, since I need a User and Role Entity for queries anyway, should I skip the forms auth or find a way to use it?
Thanks
EF and Forms Auth are really two different areas. You can use Forms Auth without ASP.NET Membership very easily and roll your own provider with very little effort.
This tutorial will show you how:
http://msdn.microsoft.com/en-us/library/ms172766(VS.80).aspx
With ASP.NET MVC you should really use standard Auth since you can manage access to controllers using attributes for Roles very easily.
FormsAuthentication on its own does not care about the identity store and can validate only credentials stored in the web.config <credentials> section, through the Authenticate method. Standard implementations of the login page use the static Membership class to manage the identities and credentials in the MembershipProvider specified in the config file (usually SqlProfileProvider).
However, you don't have to use the membership provider functionality of ASP.NET to maintain your identities and you can still use FormsAuthentication just fine. The forms authentication control flow shows that forms authentication deals primarily with creating and maintaining the auth ticket for the user in a cookie. It does not deal with the user identity or profile itself, as it does not care about those.
Thus, you can safely use EF to maintain your user profiles, including credentials and do authentication of the provided credentials in your login page, while still using FormsAuthnetication.