Reza Alirezaei’s Blog

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:

 

 

1. 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!
2. Breaking role definition inheritance also breaks role assignment inheritance, which results in unique permissions.
3. 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.
4. 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:

 

 

1. site.BreakRoleInheritance(false); only breaks RoleAssignments and has nothing to do with permission levels (Role definitions)
2. 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

---

SPWebPartCollection and IsIncludedFilter are both obsolete in V3, so I will use other new methods and properties to set the audience targeting property to a SharePoint Site Group which is part of “All Site Users” audience by default.

            SPWeb web = new SPSite(“http://server/mysite”).OpenWeb();
            SPLimitedWebPartManager wm = web.GetLimitedWebPartManager(“default.aspx”, System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);
           

            foreach (WebPart wp in webParts)
            {
                SiteUserManager sum = wp as SiteUserManager;
                if (sum != null && string.CompareOrdinal(sum.Title, wp.Title) == 0)
                {

                     sum.AuthorizationFilter = “;;;;” + web.AssociatedOwnerGroup.Name ;                    
                    wm.SaveChanges(sum);
                    break;
                }
              
            }

AuthorizationFilter is an arbitrary string to determine whether a WebPart control is authorized to be added to a page or not. You either have to give it a valid GUID of your audience or like what I did above provide the name of the group prefixed by “;;;;”.

---

Application Pool Isolation: If the same account is used in the application pool for one of your web applications and central administration, this means that your farm configuration (config DB) is editable by all users and trusted code that is registered in sites in the web application. If you can trust your developers, this is not going to be a problem, otherwise this can lead to malicious code injection and loss of your config DB in a worst case scenario.

 

 

Highly Available Central Administration Capability: If you have Only one instance of the SharePoint 3.0 Central Administration in your farm installation, you better make sure that you can administer the farm in case of a failure of a server hosting SharePoint 3.0 Central Administration. Best practices recommend that you should have SharePoint 3.0 Central Administration installed on at least two servers in your farm.

 

---

Our discussion about how other people are generating application definitions in BDC has become a controversial one (and the most popular post as well). Nick  from bdcmetaman  defends their great product and in the meantime is considering my replies as an Anti-Microsoft movement 😉 which I respectfully do not agree. It is worth taking a few minutes to read and possibly judge the point I was trying to make:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1133090

---