Setting Site Permissions during the Site Provisioning

Setting custom permissions during site provisioning can be a confusing affair. With some investigation, I was able to get the concepts clear. 

Below is the design we used for Groups and permissions in one of our projects during the site provisioning. Hope it helps you in your projects as well.

Note: All groups are created at the Site collection level. They will be visible at all the webs that will be created under it.

SiteCollection Feature Activation

1. Create custom RoleDefinitions (Permission Set) {ViewEditRD, ViewAddEditRD} at the Site Collections. This will get inherited at all the webs. Don’t get confused with the Permission breaking at the Web level.

2. Create an Admin group (SiteAdmins) at the SiteGroups collection. This will be used to provide admin activities on the Sub webs or Lists that will undergo inheritance breaking.

New Project Provisioning

1. Create the Project with Inheritance of the Permission broken.

2. Create the Custom Groups {PMGroup, TeamMebersGroup} for every Web created.

3. Associate the Custom Groups created at the Site Collection with Read permissions.

4. Associate the Custom Groups created at the Web Level with appropriate RoleDefinitions {ViewEditRD/ViewAddEditRD}. SPRoleDefinition defines the set of permissions permitted on SharePoint objects. 

5. Associate the SiteAdmins group at the Administrator role at the Web level.

6. Break the Permissions at the List level and apply the Required RoleAssignments based on the RoleDefinition and Groups. SPRoleAssignment class is used to bind together a Group and RoleDefinition with a SharePoint Object (web, list or a document library). 

Restricted Elevation in SharePoint

There are times when we would need to perform certain operations that would require elevated privileges. If your IT team is not willing to allow you to provide the necessary actions on the system account or the application pool account with all the rights, but instead use appropriate service accounts shared by other application then you would do something like this.
SPUser userImpersonated = Web.Users[@"mydomain\impersonatedUser"];
SPSite site = new SPSite("http://mywebsite", userImpersonated.UserToken);
using (SPWeb web = site.OpenWeb())
{
 // This is the section where you will use the impersonated token to do the elevated job      
 lblMessage.Text = web.CurrentUser.LoginName;
}

instead of.

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite site = new SPSite(url))
    {
        using (SPWeb web = site.OpenWeb())
        {
     // This is the section where you will do the job that requires elevated permissions
 }
    }
});