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.