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.

Service Versions: Schema Semantics

As part of your SOA governance efforts, it is not sufficient to handle just the versioning of the services and the data schemas used by the services. You must also govern the semantics of the data to enable service composability. Composite services are not possible without semantic data integration.

There are two information models in play when composing services - just as there are two different, but related, process models involved in service-oriented solutions. One is the well known common information model (CIM), the other is the related business event message model used to enable semantic business process composition.

The process composition information should be partitioned according to the business process domains to allow for the event canonical domain models (ECDM) to evolve independent of each other. Your ECDM must be federated even if evolved and versioned separately, to enable semantic data mediation and semantic business process integration.
The ECDM contains metadata that models business event messages as projections of CIM data entities. A business process message typically contains a subset of one or more domain objects. E.g. in an order handling system, the real-world event "customer submits order" is a projection of the customer, address, credit and product entities from the CIM. Think classical paper-based mail order schemas or the Excel schemas you use to get your travel expences reimbursed, or rather the form used to apply for a vacation.
Creating an enterprise canonical data model might be feasible, but federated domain models are recommended. You would anyway need to mediate semantics between your system and third-party services that you involve, or on parts of your processes that you chose to outsource.
Federated models are required for B2x integrations as you cannot easily enforce your model on the outside world. Using a CDM might work in a centrally controlled EAI hub, but most likely not across departments, organizational and partner boundaries in an extended enterprise.

WCF: WS-Security using Kerberos over SSL

WCF support typical scenarios with the system provided bindings such as basicHttpBinding and wsHttpBinding. These bindings work very well in WCF-only environments and for interop scenarios where all parties are completely WS* standard compliant.

However, interop always seems to need some tweaking, and the ootb bindings allow you to change many aspects of the binding configuration. But there will always be scenarios where these bindings just cannot be configured to fit your needs. E.g. if you need a binding that supports custom wsHttp over SOAP1.1 using a non-negotiated/direct Kerberos WS-Security token secured by TLS. In this case you need a custom binding, because e.g. even if you can turn of spnego for wsHttpBinding, you cannot tweak it into using SOAP1.1

WCF <customBinding> to the rescue:

<customBinding>
<binding name="wsBindingCustom">
<security authenticationMode="KerberosOverTransport"
requireDerivedKeys="false"
includeTimestamp="true">
</security>
<textMessageEncoding messageVersion="Soap11" />
<httpsTransport />
</binding>
</customBinding>

This custom binding combines HTTPS transport with direct Kerberos. The timestamp is required for security reasons when using authentication mode Kerberos over SSL. Note that using the UPN/SPN type <identity> element is only supported NTLM or negotiated security, and cannot be used with direct Kerberos.

WCF by default requires that the response always contain a timestamp when it is in the request. This is a typical interop issue with e.g. WSS4J, Spring-WS and WebSphere DataPower.

The response with the signed security header timestamp should be like this:

<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsu:Timestamp wsu:Id="uuid-c9f9cf30-2685-4090-911b-785d59718267" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2008-09-29T12:02:59Z</wsu:Created>
<wsu:Expires>2008-09-29T12:12:59Z</wsu:Expires>
</wsu:Timestamp>

Note the casing of the wsse: and wsu: namespace elements and attributes. This replay attact detection timestamp can be turned of using the includeTimestamp attribute, or it can be configured using the <localClientSettings> and <localServiceSetting> security elements.

Refer to the <security> element of the <customBinding> documentation for more details. Also review the settings for initiating a WS-SecureConversation if a session is needed.