Implementing claims based authorization in SharePoint 2010 provides great alternatives to using security groups in order to control access to sensitive content in SharePoint. Traditionally, security groups have been used to restrict access to content or to enforce a role based security mechanism. However, organizations are quickly finding that security groups, whether they are SharePoint groups or Active Directory groups, do not scale well in large enterprise environments. Many enterprises already have large numbers of groups deployed, so how can those organizations still make use of those groups to enforce advanced security policies without complicating group management further? As well, how can they check membership to multiple groups in order to allow access to sensitive content? This article focuses on using claim rules in Active Directory Federation Services version 2 (ADFSv2) as an efficient mechanism to enforce security policies in SharePoint based on group membership.
The Challenge with Security Groups
We’ve worked with several customers that need to enforce security policies in SharePoint which are based on a user’s membership to one or more groups. Often, large enterprises have large numbers of existing groups, typically numbering in the thousands which have been created over a period of years, and creating new groups in order to manage security is not an option because the existing set is already difficult to manage. They’re usually looking for a better solution. We have seen lately that some organizations with very sensitive content have policies that involve allowing a user access to a particular item, list, library or site in SharePoint if that user belongs to more than 1 group – for example, I mean a scenario where a user is permitted to access DocumentX if they belong to both GroupA and GroupB.
SharePoint does not easily support such a requirement. By default, SharePoint supports an OR relationship between all users/groups that have been given access to an item. So, if today I give GroupA and GroupB access to a SharePoint item, a user needs to belong to only one of the groups in order to gain access. Currently, to enforce such a policy in SharePoint requires you to manually create a third group, GroupC, which contains only the users that belong to both GroupA and GroupB. These groups are sometimes called “Intersecting Groups” because they represent the intersection of GroupA and GroupB. We can easily see how this does not scale:
- In a large environment, with many existing groups and many sites/lists/libraries/items with varying security requirements, you may need to manually create a very large number of groups (and manually determine what the intersection is)
- If the security policy requires that a user belongs to 3, 4 or more groups the problem only becomes more difficult to manage with manually
- The number of groups keeps increasing and the problem of managing a large number of groups only gets worse
- What happens when the membership of GroupA or GroupB change, perhaps because a user changes roles or teams, you will need to manually modify the membership of GroupC
ADFSv2 along its support for Claim Rules gives us a much more scalable solution to enforce such security policies in SharePoint. For more background on Claim Rules in ADFSv2 and the Claim Rule Language, please see the following previous articles:
Checking Membership to a Single Group
In ADFSv2 we can easily create a claim rule using a ‘Group Membership’ rule template – this rule would check a user’s membership to a specified AD group and use that as a condition when issuing a claim. Such a rule would be executed for each user at the time of authentication (ie. at login time) which means that a policy based on this rule will always be up to date and using the latest group membership from Active Directory.
You can create this rule by following these steps in ADFSv2:
- Click Trust Relationships > Relying Party Trusts on the left side of the ADFSv2 Console
- Right click the appropriate Relying Party Trust and select the Edit Claim Rules… menu item
- Click the Add Rule… button
- A wizard appears – in the dropdown list select “Send Group Membership as a Claim”; click Next
- Give the rule a meaningful name
- Click Browse to select the appropriate AD group you wish to check for membership
- Type in the name of the group and click Check Names – you may be required to login to the AD domain; I selected a group I had pre-created called “Finance”
- Select the Outgoing Claim Type (the claim that will be issued) and specify the Outgoing Claim Value; the Outgoing Claim Type must be a claim type that has already been created in the list of Claim Descriptions, and the Outgoing Claim Value can be any string – I selected an outgoing claim called “policydecision” and specified the value “true”
NOTE: using the ‘Group Membership’ rule template only allows you to check for membership to 1 group at a time. The wizard interface will look like it allows you to specify more than one group, but it will ultimately restrict each claim rule to only checking 1 group.
Let’s look at the Claim Rule Language for this example:
c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]
=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “true”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);
So, this rule ultimately says if the user logging in belongs to the AD group Finance, then issue the claim policydecision=true. You’ll notice that even though I selected “Finance” as the AD group to check against, the rule converted that to the group SID “S-1-5-21-563680538-1201701862-760492540-1109”. group SIDs are immutable, meaning once they are created they do not change, so this is fine. The only issue this might cause is readability of the rule language, but we can work around that.
Checking Membership to Multiple Groups
But what if you want to check 2 or 3 AD groups for membership and only if a user belongs to all of them issue the claim policydecision=true? This can easily be done by creating a custom claim rule that replicates the condition in the claim rule above and separates the conditions with &&. Since the rule converts the group name to group SIDs you’ll need to get the SIDs for all the groups you wish to check.
You can do this using 1 of 2 methods:
- Access ADSIEdit for your Active Directory, navigate to the appropriate groups, find the objectSID attribute for each group and note down their values
- Or, if you don’t have ADSIEdit access to AD, create a claim rule using the “Send Group Membership as a Claim” rule template for each group in question and then copy and paste the text from the resulting claim rule language (remember for each rule created you can click the View Rule Language… button) – you can delete these rules later
Once you have the group SID for each group, create a Custom Claim Rule and enter the following:
c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]
&& c1:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1110”, Issuer == “AD AUTHORITY”]
&& c2:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1111”, Issuer == “AD AUTHORITY”]
=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “true”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);
This claim rule will now check membership to 3 different AD groups, and only if the user belongs to all 3 groups will the claim “policydecision” with the value of “true” be returned as an outgoing claim. Be sure to replace the group SID values with the respective values for the groups you have in mind – it happened that the 3 groups I created and used all had sequential group SID values, but yours many not.
Within SharePoint 2010, if a claim of type “http://schemas.sp.local/policydecision” with a value of “true” is assigned to an item with the permission level of Full Control, then the user will only gain Full Control access to this item if they belong to all 3 groups.
Benefits of Group Membership Rules in ADFSv2
This is in fact a very efficient way of enforcing such a security policy within SharePoint 2010:
- Every time the user logs into SharePoint, group membership is validated, so policies are always using the latest information to determine what outgoing claims are returned
- No manual groups to create or maintain, especially as memberships to existing groups changes
- Only 1 claim is added to the outgoing claim set for each rule – when a user logins, ADFSv2 by default retrieves the SIDs for the groups a user belongs to as part of the incoming claim set
Note: This solution will be limited to Active Directory groups because ADFSv2 doesn’t have access to SharePoint groups.
Using TITUS Metadata Security Claims Edition with Group Membership
TITUS Metadata Security Claims Edition can automatically apply group membership policies like these to documents, items and folders in SharePoint 2010 using claims. TITUS Metadata Security has a great feature where the values of metadata columns can be used to dynamically set claims on items or folders as permissions with specific permission levels.
For example, let’s consider a situation where we have financial data in a SharePoint library that is particularly sensitive and where Contribute access is only given to members of the Audit Team, who are Senior Managers, and who are part of the Finance Department. We can enforce such a policy automatically by creating 3 metadata columns for the library with the columns named Team, Role and Department. These columns can represent the 3 groups that users must belong to in order to access particularly sensitive content. Then, in TITUS Metadata Security a policy can be created which reads as follows:
Claim Type: http://schemas.sp.local/policydecision
Value: {Team}{Role}{Department}
Permission Level: Full Control
So, an item that requires a user to be part of the Audit Team, to be a Senior Manager and to be part of the Finance Department in order to access it, can set the 3 columns as such in SharePoint. TITUS Metadata Security will then automatically generate the appropriate claim by taking the column data specified by the policy and concatenating those values together to form the claim value. TITUS Metadata Security will then apply the claim type with the generated value as permission to the item. It will apply this claim to existing content in SharePoint, as well as when new content is added or when content changes (even when metadata changes).
A corresponding claim rule must also be created in ADFSv2 that is similar to the one listed above, but with a slight change, as follows:
c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]
&& c1:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1110”, Issuer == “AD AUTHORITY”]
&& c2:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1111”, Issuer == “AD AUTHORITY”]
=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “AuditSeniorManagerFinance”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);
Since the group SIDs must be provided in the claim rule and they can only apply to specific named groups, we can simply include the group names as the value right in the issuance statement of the claim rule as shown. TITUS Metadata Security can also allow you to specify metadata conditions so that such claims are only generated and applied under specific metadata-based conditions.
TITUS Metadata Security for Microsoft SharePoint allows you to secure your sensitive data within SharePoint. Security policies can be based on users, security groups, trusted claims or some combination of the three. Policies can be applied based on existing security groups dynamically and automatically in very secure environments, without increasing the management overhead of additional security groups.
-Antonio
Comments