I have an ASP.NET project where I want to keep the membership (SQL Provider) in a separate database and the Roles/Profiles will be per application.
Question
What is the KEY that relates between the Membership database and the Roles/Profile database? Is it the UserID or UserName?
I opened up the tables in separate expolrer and notice the UserID is different in the Membership database from that in the application Roles database.
If I read your question correctly, you wish to store membership in one database instance and roles in another.
This is acceptable and possible by simply providing different connection strings. You no not need to implement a custom provider.
Understanding the fact that roles and membership are truly separate concerns, except for minor bleeding posed by the MembershipProvider.DeleteUser method, and can operate in isolation.
There is no true 'relation' between the roles and membership tables and any that are inferred by the appearance of records in the aspnet_users table are coincidental. If a record is present when a role query is made for a user, that userId is used otherwise a new record with a new userId is created.
The common value used throughout the provider stack is the username field, which, while unique to an application, is not a key.
So, as long as you are aware that you must manually perform deletion of role records when you call Membership.DeleteUser, you may simply use two databases, no custom implementation required.
Good luck
The best thing you can do in this case is implementing your own (custom) MemberShip and Role provider. The relationship between a membership and roles are defined by yourself and the username is commonly used for this.
Remark on Poet's responses:
Perhaps i shouldn't have mentioned "best solution", but in my opinion the default AspNet membership and Role provider accompanies the Aspnet tables which are created using the aspnet -regsql command. If Microsoft's Membership and Role Provider don't fullfil your needs, you should create your own.
If you create your own membership and role provider, it will be clear to other developers that they are dealing with a provider implementation which works or is structured in a different way.
My conclusion is that my solution was perhaps not "the best solution", but more a recommendation. The other thing is that the ASP.NET Providers aren't an example of good software design anyway. We are still using it, because of their compatibility with other controls. Your solution is ok, but mine will do as well and it's up to mr. Saif to choose a solution that fits best in his application.
As Microsoft mentions:
There are two primary reasons for creating a custom membership provider.
•You need to store membership information in a data source that is not supported by the membership providers included with the .NET Framework, such as a FoxPro database, an Oracle database, or other data source.
•You need to manage membership information using a
database schema that is different from
the database schema used by the
providers that ship with the .NET
Framework
Related
My first question is: Is there difference betwen apsnetmembershipprovider and simplemembershipprovider. I know that aspnetmembershipprovider is disgusting, because it always create temporary tables. so I'm wondering is SimpleMembershipProvider uses AspNetMembership sql queries or anather.
And My Second Question is what membership provider use for Web Api project, where client app will be mobile application.
this description can be helpful:
The WebSecurity helper class is the recommended way to manage user (membership) accounts, passwords, and other membership tasks. The SimpleMembershipProvider class can manage membership tasks; however, it is not recommended because WebSecurity provides a simpler way to implement membership. The SimpleMembershipProvider class is intended for developers who require more precise control over the membership process.
You can read more here, section "Remarks": http://msdn.microsoft.com/en-us/library/webmatrix.webdata.simplemembershipprovider(v=vs.111).aspx
If you don't like the way provider does the tables in the database, you could implement your own provider or use the Entity Framework Membership Provider (if you use EF): http://efmembership.codeplex.com/
I created a DbContext connection using Entity Framework and have "DbContext" connection string in my web.config file.
Then, I tried to log in, and my website required me to have another "defaultConnection" string for creating user tables.
In this case, do I need to have two connections? Or should I have one connection by somehow combining the two?
Which is better performance-wise? I started building my project using Internet Application template.
By default for membership and roles, the ASP.net infrastructure uses the default membership and role providers that stores that membership and roles data in different database. Run your application and if you register for a user from login page you can see the database at location "App_Data" folder created. The database is different hence the connection string is different. You are using entity framework so there are 2 ways to go from here.
1) Change the connection string and use the same default asp.net membership and role providers to store data in the database that your entity framework configuration is using. By this I mean the default membership and role providers use the database that you EF configuration points to.
2) Use EF to manage the membership and roles data. So the users and groups would be entities manages by the DBcontext as other entities.
I have recently implemented the second approach. The ASP.net membership provides hooks (extensibility) to implement your own providers and register them in the web.config file. Then create the User and Role entity and include them in DBContext. Of-course before registering the providers you need to implement them first by deriving from MembershipProvider and RoleProvider abstract classes. These classes are in `System.Web.Security' namespace.
You can follow this project for more details http://codefirstmembership.codeplex.com/
I believe the connections to separate database will not have any impact on the performance. As in the web model even if you use same database for incoming requests we have to make connections to database separately and the incoming requests can come concurrent. In fact keeping the database separate will take to database load to another server. But now you have 2 servers to back up and maintain. This will not be maintainable unless you want your membership data to be separate for some reasons like it is shared by other applications also.
I would suggest combining the two, since at some point you will probably want foreign key's from various tables to the Users table.
I would have one connection in the web.config, "DefaultConnection".
Then when you initialize your DbContext, use the DbContext(string) overload to use the DefaultConnection, like so: var context = new YourDbContext("DefaultConnection");
That way your data and Users/Roles tables live together, happily ever after.
I read this article here
http://www.codeproject.com/KB/web-security/RolesFormsAuthorization.aspx
What is the limitation of Membership that would require me to implement my own ?
The primary limitation is using the arbitrary database design of the Membership provider along with being relegated to the Membership API.
I have always found the membership provider API to be kludgy (at best) and the database design it requires to work out of box to be atrocious. I have never once used the builtin membership to fruition ... I think ever but absolutely not in any application I have in production.
So to sum it up, the primary reason to not use the membership provider out of box is the database design will not match your design and you will have a hell of a time trying to use your application database + membership database together or you will have a large amount of insidious data duplication of users, ASP.NET user vs application user.
Personally I've found the standard membership provider extreamly flexible. But one reason could be to allow your website to authenticate users against a legacy database containing usernames and passwords created by a different system, or to authenticate against a web service.
I've been researching this intensely for the past few days.
We're developing an ASP.Net MVC site that needs to support 100,000+ users. We'd like to keep it fast, scalable, and simple. We have our own SQL database tables for user and user_role, etc. We are not using server controls.
Given that there are no server controls, and a custom membershipProvider would need to be created, where is there any benefit left to use ASP.Net Auth/Membership?
The other alternative would seem to be to create custom code to drop a UniqueID CustomerID in a cookie and authenticate with that. Or, if we're paranoid about sniffers, we could encrypt the cookie as well.
Is there any real benefit in this scenario (MVC and customer data is in our own tables) to using the ASP.Net auth/membership framework, or is the fully custom solution a viable route?
Update: I found one person (Matt Briggs) who seems to have come to some of the same conclusions I have: This comes from this link: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1
ASP.net membership is a poorly
engineered API that is insecure out of
the box, is not well maintained, and
gives developers a false sense of
security. Authentication is a weekend
project if you aren't building a
framework, but still, most .net
developers blindly follow the official
APIs, assuming that a major
corporation like MS can put out
something decent.
One of the first rules of creating a secure authentication system is that you shouldn't try to build the framework yourself. There are many pitfalls that can be easily overlooked. So, I would say unless there is an overwhelming reason to do otherwise, you should use an existing framework like the MembershipProvider.
To list "the benefits" requires listing all security measures that were taken by the FormsAuthentication classes which is a long list. Off the top of my head, I can think a few:
Hashes of passwords
Protection against SQL injection
Protection of the cookie that stores the authentication ticket
Use of and storage of a ticket instead of say a username in the cookie.
Checking on every page to ensure the user is authenticated
Population of the IPrincipal and IIdentity for the current user
Redirection after login (granted a feature)
Handling of failed login attempts
Locking and unlocking users
ActiveDirectory integration
Ability to easily set and change password length and complexity requirements.
Salting (from Hightechrider)
....
I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.
If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.
If not, build your own, but if you do, make sure you add salt and encrypt your passwords, and do a proper encrypted cookie please.
Just to clear up a potential misconception, using the customer ID, encrypted or not is extremely vulnerable to sniffers. What you want to do instead is create a log in ticket at the time of successful authentication and store that ID in the cookie. This won't protect sniffers from stealing sessions, but at least the session (eventually) expires whereas the customer ID does not.
You can implement your own membership provider (as you mentioned) if you wish to have your own storage. One advantage is that you can administer memberships through IIS' .NET users configuration tool.
The biggest advantage is what the others stated already; why reinvent the wheel?
If you implement your own custom login UI using MVC you could reuse also when switching for a different membership provider.
You can customize to build your own provider. Behind the scenes the Membership provider uses the same FormsAuthentication implementation as you will write. Anyway, I have read that the main issues about the performance you will face will be related to the SQL SERVER stored procedures that retrieve the data. In one of the books about building a portal system by Omar Al Zabir he mentions some improvements to the stored procedure which can result in faster performance.
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.