Role-based security model in WSS 3.0 – Part1
Title: The Basics
WSS 3.0 security management is completely a role-based model. Unlike in WSS 2.0, in WSS 3.0 user permissions are never managed directly using rights (SPRights,SPRoleCollection are all deprecated in the new version). All user and group permissions are managed through roles.
A role in WSS 3.0 can be discussed in two parts:
1) Role Definition (a.k.a. Permission Level): A role definition is basically a collection of rights bound to a specific user or group. Examples of role definitions are “Full Control”, “Read”, “Contribute”, “Design”, or “Limited Access”. You can also create your own custom role definition as long as your site is using a Unique Role Definitions and not inheriting them from its parent site(site.HasUniqueRoleDefinitions==true). In most cases role definitions that come with SharePoint, OOTB , are more than enough, so the best way would be to create the permission level at the top level and not break the inheritance, but if you ever need to create your own here is how to do it:
SPWeb site = SPContext.Current.Site.AllWebs[“Site_Name/Subsite_Name”];
if (!site.HasUniqueRoleDefinitions)
{
site.RoleDefinitions.BreakInheritance(true, true); // in order to define custom role definition site must have unique role definitions
}
SPRoleDefinition roleDefinition = new SPRoleDefinition();
roleDefinition.Name = “My Custom Role Def”;
roleDefinition.Description = “A role definition with all rights except ManagePermissions”;
roleDefinition.BasePermissions = SPBasePermissions.FullMask ^ SPBasePermissions.ManagePermissions;
site.RoleDefinitions.Add(roleDefinition);
There are couple of things to remember:
- Since a role definition is scoped to the web site (SPWeb) , it has the same meaning everywhere within the Web site, but their meanings can be different from one site to another site within the same site collection and that’s the beauty of this flexible model!
- Breaking role definition inheritance also breaks role assignment inheritance, which results in unique permissions.
- The entire role definition collection is read-only for a Web site that inherits role definitions. Any attempt to add or modify the role definitions fails unless the HasUniqueRoleDefinitions property contains true, which can only be changed by calling the role inheritance methods.
- SPRoleDefinitionCollection represents all the permission levels exist in a site:
SPRoleDefinitionCollection roleDefinitions = newweb.RoleDefinitions;
2) Role Assignment: The role assignment is the only way to relate a role definition to the users and groups in WSS 3.0. If you don’t need to come up with your own custom role definition , SPRoleAssignment Class is where you spend most of your time when working with roles in WSS 3.0.
SPWeb site = SPContext.Current.Site.AllWebs[“Site_Name/Subsite_Name”];
if (!site.HasUniqueRoleAssignments)
{
site.BreakRoleInheritance(false);
}
SPRoleDefinitionCollection roleDefinitions = site.RoleDefinitions;
SPRoleAssignmentCollection roleAssignments = site.RoleAssignments;
SPRoleAssignment roleAssignment = new SPRoleAssignment(“mydomain\rezaa”,”reza@mydomain,com”,”Reza Alirezaei”,”here is the note”);
SPRoleDefinitionBindingCollection roleDefBindings = roleAssignment.RoleDefinitionBindings;
roleDefBindings.Add(roleDefinitions[“Role_Definition_Name_For Example: Full Control”]);
roleAssignments.Add(roleAssignment);
There are couple of things to remember:
- site.BreakRoleInheritance(false); only breaks RoleAssignments and has nothing to do with permission levels (Role definitions)
- SPRoleAssignment has another constructor which accepts an object of type SPPricipal. It comes in handy if you want to assign a SPGroup instead of a user to a role defintion. Remeber that SPGroup is derived from SPPrincipal and can be implicitly casted to this type:
SPRoleAssignment roleAssignment = new SPRoleAssignment(site.AssociatedMemberGroup); //AssociatedMemberGroup returns an object of type SPGroup
2. SPRoleAssignmentCollection represents all the relationships between users and groups and role definitions.
SPRoleAssignmentCollection roleAssignments = newweb.RoleAssignments;
In next part (Part 2), I am going to show you how to programmatically create subsites with unique role assignments
Karl,A couple of tnighs the administration pages hold on to the default look/feel of SharePoint due to all sites admin pages referencing a global set of style-sheets/master pages (application.master).I’m not 100% sure of what you need to accomplish but I would think it would be much more beneficial and reusable if you created a page layout based on your content type that way you can customize the look/feel of that page layout and create any number of pages based on it.I would look more closely at page layouts + content types. If that has no bearing on what you are after then the editform.aspx page is still in the forms directory of your web/site. Just keep in mind it references a master page to get the chrome now.I hope that helps Shane