Title: Subsites with unique Role Assignments
This is the second article in a series about Role-based security model in WSS 3.0. In part1 , I described the basics about this model and in this part , I am going to explain how to create subsites with unique Role Assignments.
1) First, let's create a subsite:
SPWeb web = SPContext.Current.Web;
SPWebCollection spwc = web.Webs;
SPWeb newweb = spwc.Add(this._txtBoxSiteName.Text.Trim(), this._txtBoxSiteName.Text.Trim(),"This site is created programatically", web.Language, templateCreateWeb,true, false);
newweb.AllowUnsafeUpdates = true;
2) Now we need to break the role assignments for the newly created site :
newweb.BreakRoleInheritance(false);
3) This step is to create 3 custom site groups for Visitors, Members and Owners:
//Setup Custom Owner Site Group
grpOwnersName = newweb.Name + " Owners Group";
newweb.SiteGroups.Add(grpOwnersName, web.AssociatedOwnerGroup, null, string.Format("This group is automatically created from the parent class site:{1}", newweb.Url, newweb.Name));
SPGroup grpOwners = GetSiteGroup(newweb, grpOwnersName);
//Setup Custom Members Site Group
grpMembersName = newweb.Name + " Members Group";
newweb.SiteGroups.Add(grpMembersName, web.AssociatedOwnerGroup, null, string.Format("This group is automatically created from the parent class site:{1}",newweb.Url,newweb.Name));
SPGroup grpMembers = GetSiteGroup(newweb, grpMembersName);
//Setup Custom Visitors Site Group
grpVisitorsName = newweb.Name + " Vistors Group";
newweb.SiteGroups.Add(grpVisitorsName, web.AssociatedOwnerGroup, null, string.Format("This group is automatically created from the parent class site:{1}", newweb.Url, newweb.Name));
SPGroup grpVistors = GetSiteGroup(newweb, grpVisitorsName);
4) In order for SharePoint to recognize our custom groups as the site's associated vistors,members and owners group , you need to update the following properties in your new web bucket:
//Assign Custom Groups To Counterpart Associate Groups
newweb.Properties["vti_associateownergroup"] = grpOwners.ID.ToString();
newweb.Properties["vti_associatemembergroup"] = grpMembers.ID.ToString();
newweb.Properties["vti_associatevisitorgroup"] = grpVistors.ID.ToString();
newweb.Properties["vti_associategroups"] = string.Format("{0};{1};{2}", grpOwners.ID.ToString(), grpMembers.ID.ToString(), grpVistors.ID.ToString()); //show custom groups in the quick launch when users navigate to "People and Groups"
newweb.Properties.Update();
newweb.Update();
5) Now that our custom site groups are properly set up , we need to populate them with the appropriate users. In this example I am getting users from their counterpart group in the parent site:
//Add Users To The Owners Custom Site Group
foreach (SPUser spu in web.AssociatedOwnerGroup.Users)
{
newweb.SiteGroups[grpOwnersName].AddUser(spu);
}
//Add Users To The Members Custom Site Group
foreach (SPUser spu in web.AssociatedMemberGroup.Users)
{
newweb.SiteGroups[grpMembersName].AddUser(spu);
}
6) This is the most important step in which we actually assign the permissions to the groups and as described in part1, we create Role Assignments for doing so:
// Set Permissions For Owners Custom Site Group
groupID = int.Parse(newweb.Properties["vti_associateownergroup"]);
group = newweb.SiteGroups.GetByID(groupID);
if (group != null)
{
assignment = new SPRoleAssignment(group);
role = newweb.RoleDefinitions["Full Control"];
assignment.RoleDefinitionBindings.Add(role);
newweb.RoleAssignments.Add(assignment);
}
// Set Permissions For Owners Custom Site Group
groupID = int.Parse(newweb.Properties["vti_associatemembergroup"]);
group = newweb.SiteGroups.GetByID(groupID);
if (group != null)
{
assignment = new SPRoleAssignment(group);
role = web.RoleDefinitions["Contribute"];
assignment.RoleDefinitionBindings.Add(role);
newweb.RoleAssignments.Add(assignment);
}
After all these steps, result is a sub site that is NOT inheriting its membership from its parent. This site has three sharepoint site groups in it to which you can add more users and manage them independently from its parent site.
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