Background:
I'm incorporating the SqlMembership provider into an existing system where I'm building a web front end. The Membership database will be kept in a separate database.
Beyond the login account, there's an additional mapping between the accounts that needs to be in place in the main database in order for an account to be able to log in.
Let's say that this table gives the user the right to use the system.
My question:
I would like to somehow incorporate this into the provider. Is it possible without too much work? (Or is it better to keep it in the AccountMembershipService class?)
Actually regardless, I'm very interested in learning how to put additional login requirements into the provider.
I'm asking this because when I've been looking at creating a custom membership provider earlier it seemed at that time a little bit overwhelming.
In other words:
I want to understand how to extend the Membership Provider classes in general and how to extend the login method (ValidateUser) in particular.
Given the sample ODBC implementation It looks like one simply could subclass the default provider and override ValidateUser calling base.ValidateUser as the first step.
However it may or may not be that simple, and I'd be very happy to hear any first hand experiences from implementing or extending membership providers.
I wanted to do something similar, one of the requirements was to use an Oracle DB, so I implemented the OracleMembership provider, hence I could not waste my time rewriting the hole oracle membership provider (it works pretty fine), the second requirement was to use a custom authorization legacy system. So I realized that the Internet Application template which comes with the MVC 2 or 3 comes with a small implementation of the security for the site, specifically take a look on the AccountMembershipService class. You could move all of these elements out of the MVC app to a separate assembly so you could use it even on a client implementation. The AccountMembershipService uses the Membership provider as the underlying authentication system with the option of using FormsAuthentication.
So I recommend you to take a look on that implementation. You could put your additional authentication code there so your application would stay cleaner and your don't need to re-invent the wheel and you have the chance to add your own code.
best regards
In order to extend the membership provider make you own tables with one to one relationship with the main database and handle additional requirements through this table. Also while implementing and extending the default membership provider you may need to store extra information in authcookies you may get additional information from here , here and here
In GetUserCredentials you will do your stuff for additional checking and RoleID is some dropdown on your login page that you will receive in the post method of sign in.
FormsAuth.SignIn(userName, rememberMe);
ApplicationRepository _ApplicationRepository = new ApplicationRepository();
MembershipUser aspUser = Membership.GetUser(userName);
SessionUser CurrentUser = _ApplicationRepository.GetUserCredentials(aspUser.ProviderUserKey.ToString(), RoleID);
if (CurrentUser == null)
{
ModelState.AddModelError("_FORM", "Invalid Role ");
FormsAuth.SignOut();
return View("signin");
}
Related
I've just started with MVC after working on Web Forms for 4 years. I've watched few videos explaining the architecture/fundamentals and I'm now able to replicate few modules of my old project with MVC5 using EF6.
I've a SQL Server DB containing tables such as Albums/Artists/Titles/Reviews and he User Table. I was able to work with the first set of tables using EF6 just fine including inserts/deletes. The prev project I had implemented custom Web Forms authentication using BCrypt by storing the details in the User table and later doing the validations and setting the auth cookie.
User table has details such as UserId, PWHash, EMail, FirstName, LastName. The UserId is a FK in the Reviews table and few others.
The implementation I'm hoping for is as below:
1. Login screen accepts credentials and validates with existing User table.
2. If valid, move to the 2FA screen(eMail/SMS).
3. If valid, then allow access to application.
Most of the tutorials say how to extend the attributes such as FirstName/LastName but do not say how to use an existing DB. I'm planning to use bcrypt/scrypt to encrypt the sensitive details.
I've gone through MVC 5 & ASP.NET Identity - Implementation Confusion but id doesn't have all the answers to my queries
I just need the starting point on how to plug the existing DB instead of using the dbcontext provided by default
Personally I find the documentation quite frustrating as well when you move away from th conventional, so you may be in for a world of pain.
The easiest way would be to fully take control of the authentication process yourself, utilising FormsAuthentication
However, if you want to leverage a lot of the out the box code, that has been delivered with MVC5 but against a custom database, or schema you will probably have to implement your own UserStore and maybe UserManager among other things.
The problem is, there is a lot to implement, so you are going to have a fun time guaranteed.
Have a read through this article on Custom Storage Prodivers to get a head start.
Good luck
If your app is using EF Code First then you can use your existing schema and plug in your own user. Look at the following example which shows how you can reuse your existing user information and plug it into Identity http://aspnet.codeplex.com/SourceControl/latest#Samples/Identity/CustomMembershipSample/Readme.txt
You do not have to inherit from the IdentityDbContext. You can directly use the DbContext. In this case you will have to override the onModelCreating to create the Users/ Roles tables and all the mappings between the tables.
I'm creating my first ASP.NET MVC site and have been trying to follow domain driven development. My site is a project collaboration site where users can be assigned to one or more projects on the site. Tasks are then added to projects, and users with in a project can be assigned to tasks. So a "User" is a fundamental concept of my domain model.
My plan is to have a "User" model object which contains all the information about a user and can be accessed through an IUserRepository. Each user can be identified by a UserId. Although I'm not sure at this point if I want the UserId to be a string or integer.
How should my domain objects User and IUserRepository relate to the more administrative functions of my site like authorizing users and allowing them to login? How would I integrate my domain model with other aspects of ASP.NET such as HttpContext.User, HttpContext.Profile, a custom MemberShipProvider, a custom ProfileProvider, or custom AuthorizeAttribute?
Should I create a custom MembershipProvider and or ProfileProvider which wraps my IUserRepository? Although, I can also foresee why I may want to separate the User information in my domain model from the authorization of a user on my site. For example in the future I may want to switch to windows authentication from forms authentication.
Would it be better to not try and reinvent the wheel and stick with the standard SqlMembershipProvider built into ASP.NET? Each user's profile information would be stored in the domain model (User/IUserRepository), but this would not include their password. I would then use the standard ASP.NET membership stuff to handle creating and authorizing users? So there would need to be some code somewhere that would know to create a profile for a new users in the IUserRepository when their account is created or the first time they login.
Yes - very good question. Like #Andrew Cooper, our team also went through all this.
We went with the following approaches (right or wrong):
Custom Membership Provider
Neither I or the other developer are fans of the built in ASP.NET Membership provider. It's way too bloated for what our site is about (simple, UGC-driven social website). We created a very simple one that does what our application needs, and nothing more. Whereas the built-in membership provider does everything you might need, but most likely won't.
Custom Forms Authentication Ticket/Authentication
Everything in our application uses interface-driven dependency injection (StructureMap). This includes Forms Authentication. We created a very thin interface:
public interface IAuthenticationService
{
void SignIn(User user, HttpResponseBase httpResponseBase);
void SignOut();
}
This simple interface allows easy mocking/testing. With the implementation, we create a custom forms authentication ticket containing: things like the UserId and the Roles, which are required on every HTTP request, do not frequently change and therefore should not be fetched on every request.
We then use an action filter to decrypt the forms authentication ticket (including the roles) and stick it in the HttpContext.Current.User.Identity (for which our Principal object is also interface-based).
Use of [Authorize] and [AdminOnly]
We can still make use of the authorization attributes in MVC. And we also created one for each role. [AdminOnly] simply checks the role for the current user, and throws a 401 (forbidden).
Simple, single table for User, simple POCO
All user information is stored in a single table (with the exception of "optional" user info, such as profile interests). This is mapped to a simple POCO (Entity Framework), which also has domain-logic built into the object.
User Repository/Service
Simple User Repository that is domain-specific. Things like changing password, updating profile, retrieving users, etc. The repository calls into domain logic on the User object i mentioned above. The service is a thin wrapper on top of the repository, which seperates single repository methods (e.g Find) into more specialized ones (FindById, FindByNickname).
Domain seperated from security
Our "domain" the User and his/her's association information. This includes name, profile, facebook/social integration, etc.
Things like "Login", "Logout" are dealing with authentication and things like "User.IsInRole" deals with authorization and therefore do not belong in the domain.
So our controllers work with both the IAuthenticationService and the IUserService.
Creating a profile is a perfect example of domain logic, that is mixed with authentication logic also.
Here's what our's looks like:
[HttpPost]
[ActionName("Signup")]
public ActionResult Signup(SignupViewModel model)
{
if (ModelState.IsValid)
{
try
{
// Map to Domain Model.
var user = Mapper.Map<SignupViewModel, Core.Entities.Users.User>(model);
// Create salt and hash password.
user.Password = _authenticationService.SaltAndHashPassword();
// Signup User.
_userService.Save(user);
// Save Changes.
_unitOfWork.Commit();
// Forms Authenticate this user.
_authenticationService.SignIn(user, Response);
// Redirect to homepage.
return RedirectToAction("Index", "Home", new { area = "" });
}
catch (Exception exception)
{
ModelState.AddModelError("SignupError", "Sorry, an error occured during Signup. Please try again later.");
_loggingService.Error(exception);
}
}
return View(model);
}
Summary
The above has worked well for us. I love having a simple User table, and not that bloated madness that is the ASP.NET Membership provider. It's simple and represents our domain, not ASP.NET's representation of it.
That being said, as i said we have a simple website. If you're working on a banking website then i would be careful about re-inventing the wheel.
My advice to use is create your domain/model first, before you even think about authentication. (of course, this is what DDD is all about).
Then work out your security requirements and choose an authentication provider (off the shelf, or custom) appropriately.
Do not let ASP.NET dictate how your domain should be designed. This is the trap most people fall into (including me, on a previous project).
Good luck!
Let me break down your collection of questions a bit:
Although I'm not sure at this point if I want the UserId to be a string or integer.
It doesn't have to be an integer per say, but definitely use some kind of bit based value here (e.g. int, long or guid). An index operating over a fixed size value is much faster than an index over a string, and in your life time, you will never run out of identifiers for your users.
How should my domain objects User and IUserRepository relate to the more administrative functions of my site like authorizing users and allowing them to login?
Decide if you want to use the built in asp.net membership or not. I recommend not for the reason that it's mostly just bloat and you have to implement most of the features of it yourself anyway, like email verification, which you'd think from looking at the tables generated it would be built in... The template project for ASP.NET MVC 1 and 2 both include a simple membership repository, just rewrite the functions that actually validate the user and you'll be well on your way.
How would I integrate my domain model with other aspects of ASP.NET such as HttpContext.User, HttpContext.Profile, a custom MemberShipProvider, a custom ProfileProvider, or custom AuthorizeAttribute?
Each one of these is worthy of it's own SO question, and each has been asked here before. That being said, HttpContext.User is only useful if you are using the built in FormsAuthentication functionality and I recommend using it in the beginning until you encounter a situation where it is does not do what you want. I like storing the user key in the name when signing in with FormsAuthentication and loading a request bound current user object at the beginning of every request if HttpContext.User.IsAuthenticated is true.
As for the profile, I avoid stateful requests with a passion, and have never used it before, so someone else will have to help you with that one.
All you need to use the built in [Authorize] attribute is to tell FormsAuthentication the user is valdiated. If you want to use the roles feature of the authorize attribute, write your own RoleProvider and it will work like magic. You can find plenty of examples for that on Stack Overflow. HACK: You only have to implement RoleProvider.GetAllRoles(), RoleProvider.GetRolesForUser(string username), and RoleProvider.IsUserInRole(string username, string roleName) in order to have it work. You do not have to implement the entire interface unless you wish to use all of the functionality of the asp.net membership system.
Would it be better to not try and reinvent the wheel and stick with the standard SqlMembershipProvider built into ASP.NET?
The pragmatic answer for every derivation of this question is to not reinvent the wheel until the wheel doesn't do what you need it to do, how you need it to do it.
if (built in stuff works fine) {
use the built in stuff;
} else {
write your own;
}
if (easier to write your own then figure out how to use another tool) {
write your own;
} else {
use another tool;
}
if (need feature not in the system) {
if (time to extend existing api < time to do it yourself) {
extend api;
} else {
do it yourself;
}
}
I know my answer comes a little bit late, but for future references to other colleagues having the same question.
Here is an example of Custom Authentication and Authorization using Roles as well.
http://www.codeproject.com/Articles/408306/Understanding-and-Implementing-ASP-NET-Custom-Form. It's a very good article, very fresh and recent.
In my opinion, you should have this implementation as part of the infrastructure (Just create a new project Security or whatever you want to call it) and implement this example above there. Then call this mechanism from your Application Layer. Remember that the Application layer controls and orchestrate the whole operation in your application. Domain layer should be concern exclusively about business operations, not about access or data persistence, etc.. It's ignorant on how you authenticate people in your system.
Think of a brick and mortar company. The fingerprint access system implemented has nothing to do with this company's operations, but still, it's part of the infrastructure (building). As a matter of fact, it controls who have access to the company, so they can do their respective duties. You don't have two employees, one to scan his fingerprint so the other can walk in and do its job. You have only an Employee with an index finger. For "access" all you need is his finger... So, your repository, if you are going to use the same UserRepository for authentication, should contain a method for authentication. If you decided to use an AccessService instead (this is an application service, not a domain one), you need to include UserRepository so you access that user data, get his finger information (username and password) and compares it with whatever is coming from the form (finger scan). Did I explain myself right?
Most of DDD's situations apply to real life's situations... when it comes to architecture of the software.
I have been tasked with implementing point 4 in this article: http://support.microsoft.com/kb/900111
This involves using the Membership provider to add a comment to users server side records when they log in and out, and then confirming that when a cookie is used to authenticate, that the user hasn't logged out. This makes perfect sense to me. Where this starts to fall apart is that we do not currently use a membership provider, and so it seems like I face reimplementing all our authentication code to use a membership provider. We currently check authentication in a controller, and make a call to FormsAuthentication.SetAuthCookie() once we know the user exists. It would be a lot of work to force a membership provider in.
Is all this work really neccesary. Can I roll my own key value store of cookie values to logged in users and just make sure I clear this when a user hits the logout button. If this seems unsafe is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?
I guess my main problem here is that we decided a long time ago that the membership provider model doesnt fit with the model we use for locking and unlocking accounts, and chose not to use it. Now we find that the MS recommendations specifically mention a membership provider, and as this is security I need to be sure that not using it as they recommend isn't going to cause troubles.
Can I roll my own key value store of
cookie values to logged in users and
just make sure I clear this when a
user hits the logout button.
Yes, you can do this. The Membership Provider keeps a small set of data about the user (username, email, password, last login, lost password question, lost password answer, etc).
If you don't want to retro fit a membership provider I would take the approach you mentioned. Whether the information is written to the comment field of the aspnet_Users table or a bit field in your own table, it shouldn't make any difference.
You also might want to consider putting an interface your Membership/Authentication code. Then you could swap your current code to a Membership Provider implementation when it's more convenient.
I've found the MembershipProvider to be very helpful. It allows me as a developer to use the SQLMembershipProvider against a local database of users, and then when I move it to production, to simply use an ActiveDirectoryMembershipProvider and I don't have to change a line of code (except in my web.config file).
Using their CustomMembershipProvider, you can overload any of the authentication methods and do whatever other checks you want inside of those methods.
If you decide to jump to the MembershipProvider scheme, I don't think you'll regret it. It may be painful in the short term, but in the long run, I think you'll see it paid off. Since you've already got a lot of your authentication code written in your controller, perhaps it won't be that hard to meld it into the way MembershipProvider uses it?
...is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?
MP is one of those times when its best to let it do what it does best. If you try to use just part of it here and part of it there, while possible, will cause some headaches down the road. It knows what it is supposed to do and circumventing it, while possible, will require extra work that may turn out to be unnecessary.
In a website, I need to integrate membership and authentication. So I want to use the functionality of ASP.NET Membership, but I have other custom stuff, that a "user" has to do.
So I am sitting here with my pencil and paper, drawing lines for my domain model... And how can I best utilize the ASP.Net membership, but extend it to fill my needs?
Should I create a class that inherits from a MembershipUser and extend it with my own properties and methods (and save this in a seperate table). Or should I let the MembershipUser be a property on my custom User/Client object?
What would be a good solid way to do this?
I've thought about it and there are 2 ways that seem appropriate (of course there are more ways to make it work).
Custom Membership Provider
You change the membership provider to use your own and use your User object to store all the information.
The problem with this one is that it involves a lot of re-implementation of things that are already well handled by Asp.Net. The good thing is that you have a single User object with all the details.
Link from a Membership User to your User
With this method, you would use the original Membership provider to handle the user name and password, but you link your own User object with this one with something like the user name by using a service for example.
It's really easy to set up, you just need to create a service that would be used like this:
string userName = "Jon Skeet";
User user = new UserManagementServices().GetUserByUserName(userName);
I ended up writing my own membership-provider, and have implemented that in 3 separate solutions now. It is extremely simple and much, much more elegant than linking a user to a membershipUser (which I have also tried).
Read this...:
Create Custom Membership Provider for ASP.NET Website Security
And if you want to learn more, watch this video (with sourcecode).
I've extended MembershipUser and created my own version of the SqlMembershipProvider to map to my existing domain, and its working well, in production now.
MembershipUser is essentially a view over my User table. My extended MembershipUser class includes profile/account-style properties instead of using the default SqlProfileProvider system, which is a bit fragile.
I wasn't able to use the existing membership tables or sprocs, but wrote my own. For example, the SqlMembershipProvider uses a GUID as an opaque key, but the production system uses a plain old int. All of the dates are UTC, etc. too.
All of the extra User functionality is accessed via the User domain not via Membership methods.
HTH.
I'm currently working through the Microsoft ASP.NET 2.0 Membership API Extended article from CoDe Magazine which explains how to extend the membership API by writing a wrapper around the existing classes. Main benefit is that you can keep all the out of the box functionality and not have to rewrite your own as you would when implementing a custom provider. Source code is provided.
I'm in need of a RoleProvider with the following functionality:
Dynamic Assignment of Roles to Tasks
Authentication / Authorizaiton of IPrincipals based on the dynamically allocated tasks in the system they have privilege to access
Reporting showing who is currently logged in, and other common usage statistics.
I'm pretty sure I'm going to have to roll my own, but wanted to make sure I didn't miss out on something OSS or even from MS.
I'm also using ASP.NET MVC and so my basic plan is to write a custom attribute like: [Authorize(Task=Tasks.DeleteClient)]
and place it over the methods that need authorization.
Rather than authorizing against the Role, I'll authorize the task against the role based on whatever settings the user has configured in the DB.
Thoughts?
You might want to check out NetSqlAzMan. It allows you to define tasks and assign them to roles and then authenticate and authorise your IPrincipal objects.
You may need to roll your own security attribute but NetSqlAzMan should help make that a reasonably easy task.
We had a similar issue with one of our systems. The first thing I'd do is create more AuthorizeAttribute classes for your specific tasks - e.g. DeleteClientAuthorize etc. You can then add specific logic into your classes.
As long as you can access the routines that trigger the change of roles for the current user you should be OK. Just call Membership.DeleteCookie() and this will force the next authorisation request to re-query your data store. It's at that point that you can determine what roles are required now.