I have a project that is not released yet I will not be soon but I moved it from mvc3 to mvc4 a few days ago and while reading I saw this new security provider SimpleMembership.
The way I implement security now is by using MembershipProvider and FormsAuthentication:
To register user I use:
MembershipCreateStatus status;
Guid g = Guid.NewGuid();
Membership.CreateUser(model.User.Email.Trim(), model.Password.Trim(), model.User.Email.Trim(), null, null, true, g, out status);
if (status == MembershipCreateStatus.Success)
...
FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
1,
tUser.Email,
DateTime.Now,
DateTime.Now.AddDays(60),
true,
userData);
string encTicket = FormsAuthentication.Encrypt(authTicket);
HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
Response.Cookies.Add(faCookie);
...
But as I saw SimpleMembership looks much cleaner and I want to move project to it
but I have some questions about it:
1) I use stored procedures for all database actions I don't use EF at all. If I use SimpleMembership is it possible to use it without EF?
2) Do I need to build custom SimpleMembership for real world application?
3) I saw that it seeds database Create tables. I have my tables Users, Profiles, Roles and UsersInRoles can I apply it to my custom schema?
4) If I want to call WebSecurity.CreateAccount(...) and I want to call some my custom method from domain project that is responsible to call stored procedure that create user do I have to make it custom and if I have to do that is there some resource that explain how to make it custom for users and roles?
To understand SimpleMembership and how it has evolved from, and depends on, the previous Membership implementation, I recommmend reading the original reference "Using SimpleMembership With ASP.NET WebPages (Matthew Osborn)", and my more detailed answer to "What is MVC4 security all about?" to understand it better. To summarise those references:
SimpleMembershipProvider and the SimpleRoleProviderSimpleMembershipProvider
ExtendedMembershipProvider abstract base class, such as integration with OAuth providers out of the boxwebpages_Membership, webpages_OAuthMembership, webpages_Roles, webpages_UsersInRoles) and one (UserProfile) which is yours to structure as you wishWebSecurity helper class to add new functionalityUserProfile table (which is fully customisable using EF)To answer your specific questions:
1) I use stored procedures for all database actions I don't use EF at all. If I use SimpleMembership is it possible to use it without EF?
You would not generally interact directly with the tables prefixed with webpages_ as there are API level functions in Membership, WebSecurity etc. to do all the business functions you require. However there is nothing to stop you interacting with UserProfile through stored procedures, and if you didn't want to take advantage of the APIs, you could even interact with the webpages_ tables through sprocs as well (but you would just be duplicating all the benefits of SimpleMembership if you did).
2) Do I need to build custom SimpleMembership for real world application?
That very much depends on what you want to do, but as yet I have not had to do this for any real world applications. I have built on and added to the existing APIs, but not replaced them.
3) I saw that it seeds database Create tables. I have my tables Users, Profiles, Roles and UsersInRoles can I apply it to my custom schema?
If you were migrating to SimpleMembership you would have to port the data in these to the tables webpages_Membership, webpages_OAuthMembership, webpages_Roles, webpages_UsersInRoles and UserProfile. However, note that UserProfile can be called anything you want, you don't have to call it UserProfile.
4) If I want to call WebSecurity.CreateAccount(...) and I want to call some my custom method from domain project that is responsible to call stored procedure that create user do I have to make it custom and if I have to do that is there some resource that explain how to make it custom for users and roles?
Its a little hard to understand your requirement, however WebSecurity.CreateAccount does the following:
webpages_Membership and UserProfile if you use WebSecurity.CreateUserAndAccountIf you wanted to do other actions across your database you would then need to call that after your call to WebSecurity.CreateAccount. You can make this transactional by using TransactionScope
If however you wanted to wrap this all in a single call to WebSecurity.CreateAccount and make it call your own domain methods and stored procedures you will have to create your own provider by inheriting from SimpleMembershipProvider (or from ExtendedMembershipProvider). When WebSecurity.CreateAccount then calls ExtendedMembershipProvider.CreateAccount it will defer to your custom logic
Summary
So would I migrate? The benefits of SimpleMembership are meant to be:
WebSecurity, and continued support of existing features with MembershipAuthorize attributeIf those help you out, then migrate, otherwise spend your dev time on new features for your application.
If you do decide to migrate, then "Migrating Legacy Apps to the New SimpleMembership Provider (Paul Brown)" is useful, which is summarised as:
UserProfile to have a field per property for your old user profile properties that were stored in xmlaspnet_ tables to the webpages_ tablesMembership one (see the footnote to my answer here for how to do this)