In my last post I mentioned that it would be nice to be able to use a security group in other site collections. This was so that I wouldn’t have redundant security groups to provide access to the Web Part on the home page and to the actual site. It turns out that these groups cannot be shared across site collections or web applications, but they don’t need to be.
If you create a new site from an existing site (by going to Site Actions-> Create Site) it will inherit all of the security groups from the parent site. Doing this pushes security settings down through the site collection tree; people who have access to the parent page will have access to the child. Microsoft suggests that if you don’t want this behavior then you should just create a separate site collection; however, we can override this behavior.
I did not want to have the groups that I set up for my main site have permissions to every site that I create. In fact, I wanted the lower level sites to have more granular permissions, and then use those on the main page to change the look based on who is logged in. To do this, it seems that I have to override the inheritance structure. Overriding this allows me to add new groups to the children sites that have access to the site but don’t get applied to the other children sites. To do this:
- Go to the Site Settings of the child site, then to People and Groups
- Go to “Site Permissions” and then click Actions->Edit Permissions. This will pop up a message box telling you that changes to the Parent site will no longer affect this site. This means that your Parent site’s permissions need to be completely set up before you start this process.
- Next, go to New->New Group. On this page you can give this group the permissions you want it to have for this site. If you tried to create a new group before the last step you would not have been able to give it permissions to this site.
- Now when you go back to your main site, you can use this new group as the target audience for a Web Part.
The issue here is that if you decide later that the permissions further up the Site Collection tree need to be changed, they will not be pushed down because you broke the inheritance. You can have a site re-inherit from above, but then you lose all your custom permissions; however, the groups that you created stick around.
An alternative approach would be to have all of your groups at the top level and then turn off permissions as you go down the tree. The difference here is that instead of re-adding permissions after inheriting from the parent you are re-removing permissions. I would suggest the former because there is less work involved, i.e. fewer groups to play with.
Either way, this is breaking the inheritance idea a little bit, but it does allow for you to use one permission group to control what is happening on multiple pages. It allows you to use permission groups up a tree instead of just down it as well.
