Jay Kimble

So I’m doing a little preparation for my Membership talk next weekend (this is going to be more of a chalk talk, btw… more Q&A, hopefully).

I just realized that after creating the database and adding a user that I wasn’t really sure what each database role meant so (I always choose the 4 “full” roles and move on).  So I decided to tear apart the various roles (and throw the SP exec permissions here).  At the end I’ll tell you what I think it all means (I’m sure there’s an MS Whitepaper with this stuff buried in it… I’d just rather dig in and figure it out myself)

Membership Basic Access
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      Membership GetNumberOfUsersOnline
      Membership GetPassword
      Membership GetPasswordWithFormat
      Membership GetUserByEmail
      Membership GetUserByName
      Membership GetUserByUserId
      Membership UpdateUserInfo
Membership Reporting Access 
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      Membership FindUsersByEmail
      Membership FindUsersByName
      Membership GetAllUsers
      Membership GetAllUsers
      Membership GetNumberOfUsersOnline
      Membership GetUserByEmail
      Membership GetUserByName
      Membership GetUserByUserId
      Membership GetUserByUserId
Membership Full Access (all of Membership Basic and Reporting permissions)
   SP Exec Access -
      Membership ChangePasswordQuestionAndAnswer
      Membership CreateUser
      Membership ResetPassword
      Membership SetPassword
      Membership UnlockUser
      Membership UpdateUser
      Users DeleteUser
Personalization Basic Access
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      Paths CreatePath
      Personalization GetApplication
      PersonalizationAllUsers GetPageSettings
      PersonalizationAllUsers ResetPageSettings
      PersonalizationAllUsers SetPageSettings
      PersonalizationPerUser GetPageSettings
      PersonalizationPerUser ResetPageSettings
      PersonalizationPerUser SetPageSettings
Personalization Reporting  Access 
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      PersonalizationAdministration FindState
      PersonalizationAdministration GetCountOfState
Personalization Full Access (all of Personalization Basic and Reporting permissions)
   SP Exec Access -
      PersonalizationAdministration DeleteAllState
      PersonalizationAdministration ResetSharedState
      PersonalizationAdministration ResetUserState
Profile Basic Access 
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      Profile GetProperties
      Profile SetProperties
Profile Reporting Access
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      Profile GetNumberOfInactiveProfiles
      Profile GetProfiles
Profile Full Access (all of Profile Basic and Reporting permissions)
      SP Exec Access -
      Profile DeleteInactiveProfiles
      Profile DeleteProfiles
      Profile DeleteProfiles
Role Basic Access
   SP Exec Access -
      CheckSchemaVersion
      RegisterSchemaVersion
      UnRegisterSchemaVersion
      UsersInRoles GetRolesForUser
      UsersInRoles IsUserInRole
Role Full Access (all of Role Basic and Reporting permissions)
  SP Exec Access -
    Roles CreateRole
    Roles DeleteRole
    UsersInRoles AddUsersToRoles
    UsersInRoles RemoveUsersToRoles
Role Reporting Access 
  SP Exec Access -
    CheckSchemaVersion
    RegisterSchemaVersion
    UnRegisterSchemaVersion
    Roles GetAllRoles
    Roles RoleExists
    UsersInRoles FindUsersInRole
    UsersInRoles GetRolesForUser
    UsersInRoles GetUsersInRoles
    UsersInRoles IsUserInRole
WebEvent Full Access 
   SP Exec Access -
    CheckSchemaVersion
    RegisterSchemaVersion
    UnRegisterSchemaVersion
    WebEvent LogEvent
 SPs with no permissions for any role (only meant for maintenance purposes
    AnyDataInTables
    Applications CreateApplication
    Setup RemoveAllRoleMembers
    Setup RestorePermissions

Membership access
There are 3 membership access types.  Basic, Full, and Reporting. 

Basic seems to for providing simple authentication; this type of role doesn’t provide for creating users.  Basic seems like it would be a good fit for sites (or Windows apps) that only allow the user to login (and not create accounts).

Reporting seems to me to provide the ability to take a look at the membership.  Maybe you want to provide some way for a non-admin to look at activity on the application without giving this app full admin capabilities.  You can check to see how many users are online, look at all the users registered, etc.

Full combines the Basic and Reporting and adds a few more capabilities.  It provides a numerous additional user management features.  It would be a good choice if you want to provide the concept of letting a user come in and “join” the site (“approval” may be a separate function), or if you are providing the admin utility for an application that uses the basic role then you would need this role.

Personalization Access
There are 3 personalization access types.  Basic, Full, and Reporting (admittedly I’m a little weak in this area).

Basic access lets you provide functionality where a page can be personalized globally as well as by the specific user.

Reporting lets the application find a particular state as well as to get a particular state (not sure what this means right at the moment… by Saturday I’ll be a lot more boned up on this area).

Full adds the ability to delete/reset various states.  It gives you complete control over the user personalization features.

Profile Access
You guessed it! There are 3 access types – Basic, Reporting, and Full.

Basic access simply provides the ability to get/set properties (variables that are associated with a user).  You would use this for an application that needed no other access then to let an individual user customize there experience within the application.

Reporting access provides a way to look to see how many profiles (sets of variables) are inactive as well as to get a listing of all the profile data.  This would be useful if you wanted to create an application that reported on the user settings without providing actual administration access (to modify other users profiles.

Full adds to the other access the ability to delete inactive profiles or to reset profiles (in various ways).  This is definitely the permission to use if your app will provide

Role access
Yep, 3 types of access: Basic, Reporting, and Full.

Basic access provides simple access to see if get the roles a user is in as well as to check which roles a user is in.  Good for simple apps where the roles will be control via some other mechanism.

Reporting access provides inquiry support into the user and roles allowing the app to simply see which users have access or to see which roles exist, etc.  This role is good for those apps that are for role audit on another app (or to provide the feature).

Full access combines the Basic and Reporting roles and adds the ability to add and delete roles as well as to add/remove roles from users.  This role would be good for an app that needs to provide admin tools as well as basic role retrieval or for an admin app for an app that uses the basic role.

WebEvent access
Only one type of access here : full.  Full access let’s your app call LogEvent.  I’m not 100% sure what this is for.

Additional Stored Procs
Obviously, there are stored procs whose use is to provide DBAs (or programmers) the ability to manage the security system.  These features are for the use of administrators and probably shouldn’t be used within an app (although “Create Application” could be useful).

[tags:ASP.Net,Membership Provider,.Net Provider models, .Net Security Providers]