Friday, October 17, 2008

SharePoint ACLs: RoleDefinitions, RoleAssignments, Inheritance

It's been a long time since my last SharePoint post, and this must be my first post on MOSS and WSS3.0. There have been a significant change from WSS2.0 in the underlying security model for access control on sites, lists, items, libraries, folders and documents - and these are some findings that should make it easier to understand the new model.

Permission Levels have been replaced by Role Definitions, and Permissions have been replaced by Role Assignments. While this is not reflected in the SharePoint UI, the authorization object model is new.

The rights are assigned to securable objects that are referred to as 'scopes' as the rights of a user or group
by default are inherited throughout the contents of a site (SPWeb). Thus, if you have only read access to a site, this scope will by default give you read access to all contents of the site - unless some contents have been configured to not inherit permissions, and are thus in a separate scope.

Both Role Definitions (RD) and Role Assignments (RA) are by default inherited, but both can be broken to not inherit from it's parent. A site can break the RD inheritance to define new roles or change or delete existing roles (except 'full control' and 'limited access'). RD definitions always applies to the whole site, while permission (RA) inheritance can be broken at several securable object levels. This makes it possible to have unique permissions for e.g. lists or even list items.

Role definition inheritance in a Web site has impact upon permissions inheritance in accordance with the following prohibitions:
  • Cannot inherit permissions unless it also inherits role definitions.
  • Cannot create unique role definitions unless it also creates unique permissions.
  • Cannot revert to inherited role definitions unless it also reverts all unique permissions within the Web site. The existing permissions are dependent on the role definitions.
  • Cannot revert to inherited permissions unless it also reverts to inherited role definitions. The permissions for a Web site are always tied to the role definitions for that Web site.
Thus, in order to have unique role definitions you must have unique permissions (role assignments), but unique permissions can have either unique or inherited role definitions. Inherited permissions must have inherited roles.

If a site do not have role inheritance, then reverting to inherited roles will also revert unique site permissions into inherited permissions. Reverting to inherited permission for a subsite discards custom permissions, permissions levels, users, and groups that were created for the subsite and all it’s lists and contents.

What can be a bit confusing about the authorization object model is that there are two methods for breaking the inheritance of RDs and RAs respectively, but only one to revert inheritance:

  • SPWeb.RoleDefinitions.BreakInheritance (bool CopyRoleDefinitions, bool KeepRoleAssignments)

  • SPWeb/SPList/SPListItem/SP*.BreakRoleInheritance (bool CopyRoleAssignments)

  • SPWeb/SPList/SPListItem/SP*.ResetRoleInheritance()
This asymmetry is an effect of the above role and permission inheritance rules and prohibitions. As soon as you revert the unique permissions of a site using SPWeb.ResetRoleInheritance, you cannot have unique roles and thus inherited role definitions will be in effect.


Anonymous said...

I have an issue while breaking role inheritace of a doc library
after breaking the role inheritance of its child. the problem is that the role assignments in the folder got vanished other than the system account with full control

Kjell-Sverre Jerijærvi said...

The role assignments where lost even if you used CopyRoleAssignments = true?

Do you still inherit the role definitions?

Anonymous said...

Kjell , thanks for your reply

I dont need to copy role assignment

What i need is to first break the role inheritance in the folder with in a doc-library.
I am adding a new user here.

next I need to give a diffrent role to the same user in the library.I do the following steps

1.Break the inheritance at library.
2.Create the groups for library (I am using AD groups)
3.Remove the users if the library inheritance is already broken from the sibling group.(I dont want the same user in the sibling group at library)

4.Add user to the group.

5.Do the role assignment to the Library

Now at library level every thing is fine. But In the folder (under library , were i broken the inheritance before by adding a new user) all the role assignments got lost other than system account-full control.

I dont want to copy role assignment from a parent at any point of time. Because each level i need new role assignment.

I am using folder1.BreakRoleInheritanc(false);

Kjell-Sverre Jerijærvi said...

If you don't copy the role assignments when "breaking" the folder, all assigned rights (ACLs) will be gone.

Wael Kabli said...

thanks a lot for your excellent explanation :D