I have always stayed away from asp.net membership as it seemed bloated, and (at the time) untestable. In the case of asp.net MVC specifically, does anyone use an alternative solution for assigning roles to users, and storing some addition information for the logged in user? Any recommendation? Is it crazy to just roll your own, just implementing the functionality you need?
ASP.NET membership uses a provider model for the storage. SqlMembershipProvider inherits encrypting/hashing password functionality from the abstract MembershipProvider class. But you could also inherit from MembershipProvider and get that functionality in a custom provider if you wanted.
If you use the SqlMembershipProvider, you get a fully working membership database with full password management (checking, changing, resetting, invalid password attempts) and user management (CRUD ops, locking out users).
All of that is at an API level. You can create whatever UIs you want against the API.
Using the SqlMembershipProvider doesn't require you to use the Roles Provider or the Profile Provider or any of that other stuff, and you can roll your own for those things without impacting membership. At the very least I would recommend using the well-tested SqlMembershipProvider as the core of your security for the basic stuff.
I have successfully implemented DotNetOpenAuth as a membership and role provider. It is not a full implementation but handles most common scenarios.
They provide VS templates to get you started.
Related
This is not like other questions you might find similar. My issue is way bigger.
Scenario:
I have 3 websites. All of them have a common database for authentication and stuff.
Problem is that i will need to expand to 2 more sites, which means more maintenance in login screens and so on. So i will dedicate time to make a "central website" to manage users, access, etc.
Also, Need to implement OpenId for Microsoft Works accounts (ie, Azure tenants).
DDBB User Model: (Simplified)
All users are in the same central database. Which does not contains
anything non-user related.
User is personal on all applications.
Users can have different Roles
Each "User-Role" is mapped to an application, a server and a
database.
Problem:
Created a site in AspNet Core, without any authentication done so I can do it myself since I found that mapping Aspnet Identity tables was no-go because of incopatibilities and overriding is way to complicated, specially when dealing with Managers.
So, Tried and got working a simple Authentication page using HttpContext.Authentication.SignInAsync and CookieAuthentication. Which works well and there is no need to use any of the Identity's implementation (which is not compatible with my backend).
But then I added UseOpenIdConnectAuthentication to have the OpenId auth, but I have no idea how to use it since its suposed to work out of the box when using Identity and when checked documentation they use this code in an controller action: signInManager.ConfigureExternalAuthenticationProperties and I do not have any SignInManager since Im not using Aspnet Identity.
Questions:
Is coping the source of ConfigureExternalAuthenticationProperties to make it work in my site an aceptable solution?
Should I continue to override all SignInManager methods and also probably implement other classes to make Aspnet Identity work with my model?
Tried Mapping the properties to my columns just to test it out and it gave me non debuggable errors, which i dont like to even think about the problems this can give me in the future. For example one error was that it coudnt parse byte[] to string.
How can I implement Microsoft Work Accounts authentication and Database authentication in the same AspNet Site?
Bonus topic
Recently I feel like programming is becoming Configuring instead of coding. Is it just me? Are we now Professional Configurers?
Thanks
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 multi-tenant application where each tenant will have their own database. The ASP.NET MVC3 web application will look at the username passed in and determine which customer database to use to authenticate the user.
I can get this to work if I add multiple connectionStrings / membership Providers, I can get it to work.
I'd like a way to remove the dependency on the web.config.
Is there a way to configure SqlMembershipProviders via code and not tie myself to a web.config file? I'm thinking I could do it with a custom provider that I write, but would like to see if there was a way before heading down that road.
I've become less of a fan of using the ASP.NET Membership provider for my MVC projects that deal with user data in other ways. Instead, I use forms authentication and incorporate the password hash and salt as columns in my user database (similar to the schema) then manually set the forms authentication cookie.
This is actually not dissimilar from what the default MVC project scaffolding sets up. I just didn't like having to correlate my user records with ASP.NET membership records and I didn't make use of the associated profile or role capabilities.
If you go this route, then you have some options as to how to handle a multi-tenant scenario, but I seriously doubt you'll be able to (or want to, for that matter) get rid of the web.config altogether.
For some multi-tenant ideas, check out my answer in this SO question: SaaS: one web app to one database VS. many web apps to many databases
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.
We have started building an asp.net mvc application. Application will consist with one main database with users, projects, common tables etc... and many databases (all with the same structure) with a data relevant to a particular project. Use can have some global roles (stored in a main database) and some project specific roles (stored in a project database) and each user can be linked to many projects.
My goal is to build an authentication system that will support classical username/password authentication and also an OpenID authentication (we are using DotNetOpenAuth for this purpose) and authorization system that will support the roles system which I described above.
But I run into several question:
1.) I think that we should support both (username/password and Ppenid) authentication options for a single user, so that username/password users won't need to create additional account when they decide that they will use an OpenId and I think that we should support several OpenId's for a single user like SO does (if some provider is down).
2.) I think that the best database for this would be:
table Users (UserId (PK), LastActivityDate)
table UsernameLogins (UserId (PK,FK), Username, Password, IsApproved, IsLockedOut, LastLoginDate, LastLockedOutDate, etc...)
table OpenIdLogins(OpenIdUrl (PK), UserId(FK),LastLoginDate)
table Profiles(UserId(PK,FK), DisplayName(Unique), Email (Unique), FirstName, LastName, Address, Country, etc...)
table Roles(RoleName (PK), RoleType(1=GlobalRole,2=ProjectRole).
table UserRoles(UserId(FK,PK), RoleName(PK)).
3.) Should I create my own providers (MembershipProvider, ProfileProvider, RoleProvider)? Its seems that MembershipProvider is not so appropriate for an OpenId authentication (and of course I can only support just basic methods (GetUser,ValidateUser))? Should I implement MembershipProvider just for username/password logins? I think that ProfileProvider and RoleProvider wouldn't be that hard to implement? Should I just use FormsAuthentication and use my own "services"?
We are also using NHibernate and Spring for DI.
Any advice will be appreciated.
Thanks!
1.) I think that we should support both (username/password and Ppenid)
authentication options for a single
user, so that username/password users
won't need to create additional
account when they decide that they
will use an OpenId and I think that we
should support several OpenId's for a
single user like SO does (if some
provider is down).
That seems reasonable. I like how you're designing in for users to have multiple OpenIDs. StackOverflow limits users to just two, but users often have more than that and may want to bind them all. I think username/password is a fine option if your target audience demands it OpenID. StackOverflow is a great example of how simple login can be when its pure OpenID. It can make login less busy to not offer username/password. But again, providing both as options seems most customer-focused since it gives them choice. A future version of DNOA will offer an integrated version of the InfoCard Selector into its OpenID login system so that you can even accept InfoCards directly, but have it look and feel just like an OpenID so your system won't require any changes.
2.) I think that the best database for this would be: <snipped/>
That looks like a reasonable schema. As you've discovered, separating the credentials tables gives you the greatest flexibility.
3.) Should I create my own providers (MembershipProvider, ProfileProvider, RoleProvider)?
MembershipProvider certainly doesn't fit OpenID very well. If you were only supporting OpenID login I'd say throw it out and don't bother implementing your own. The RoleProvider works perfectly with OpenID so that's a keeper. I've heard from others that ProfileProvider needs a MembershipProvider in order to function. I don't know if that's true. But ProfileProvider requires that you use the ASP.NET Membership SQL database schema, which I think is poor if you can write your own db schema which you've done. And if you're writing your own db, storing additional data about your users should be trivial so you shouldn't need the profile provider.
If you go with both username+password and OpenID, then having a MembershipProvider that you implement yourself would likely be possible, but in my experience most MembershipProviders that include any OpenID code are kludgey and even have security holes. So I'd still avoid the MembershipProvider if OpenID has any place in your system.
I wonder...is support for multiple OpenIDs that important. It seems like this is more the role of the OpenID provider. For example, I use ClaimID and I get what essentially amounts to "identify forwarding" (in the sense of email forwarding) so that I can rebind it to different identities. Now I don't rebind providers frequently but a provider could do this (i.e. when you get redirected to their login page they could ask you which identity you'd ultimately like to present). So the question is...is this really the applications job to implement?