SharePoint MetaData and Classification

Fail Safe Security for Microsoft SharePoint

Microsoft SharePoint is used in many highly secure environments around the world that deal very sensitive information – information that is considered ’secret’ or ‘top secret’ and where security of that data is critical to not only business but also to national security. These deployments exist primarily in military and government installations, or as part of the intelligence community. In these SharePoint deployments, its extremely important that security and access control policies be configured in such a way that they “Fail Safe”.

The concept of “Failing Safe” means that if the security system which implements the access control policies fails, for whatever reason, that sensitive information will automatically have the most restrictive access rights automatically applied. Therefore, in these cases, if such a system failure occurs then the sensitive information that is being protected is not left open and in the clear, allowing non-authorized users to access it.

Examples of an access control policy system failing could be an authorization server going down, it could be an inadvertent reboot of a server, or it could even be an unauthorized user gaining access to the environment and interrupting communication between the authorization system and the content management system (SharePoint). There are many such examples. Hardening critical infrastructure and protecting it against all possible forms of attack or circumstances that might arise is a very difficult task that must be performed. However, you also want to ensure that you look at this problem from the point of view of: if all else fails, then access to my sensitive information will revert back to the most restrictive access rights possible so that my sensitive data is not inadvertently released.

TITUS Metadata Security for SharePoint uses trusted claims about a user, and combines them with document metadata to ensure that the right people are accessing the right information in SharePoint. TITUS Metadata Security automatically applies fine grained access control to SharePoint content using the SharePoint permissions system. This has the advantage of enforcing the access control policies that administrators or site owners configure on all the mechanisms that information workers can use to access content within SharePoint, including the SharePoint web view, the explorer view, search, FAST search, the client object model, the server object model and any web services that may be deployed. With TITUS Metadata Security, policies are dynamically enforced, so that as a user’s identity changes or as metadata changes, security policies are automatically applied and user’s are only accessing the content they are permitted to access.

TITUS allows you to set the default permissions on all content within SharePoint to the most restrictive access rights possible. Then when defining access control policies and enforcing those policies with TITUS Metadata Security, TITUS will simply add the appropriate access rights for specific users, groups, or users with specific claims to only gain access to sensitive content that they are permitted to access . This allows Microsoft SharePoint to “Fail Safe” so that if a malicious user or a failure in process subverts the access control policy system, that your sensitive information will revert back to its default inherited SharePoint permissions (the most restrictive access rights possible) and still remain secure!

There are several other systems on the market which implement access control policies or entitlement management in Microsoft SharePoint. However, these systems often require that default permissions on all content be initially configured to the most open access rights possible. The issue here becomes that if that access control system were to be subverted or fail, for whatever reason, and if SharePoint then reverts back to its default inherited permissions then all content including your most sensitive content will be inadvertently leaked. TITUS Metadata Security for SharePoint is the only leading fine grained security system for Microsoft SharePoint that allows SharePoint to”Fail Safe”.

TITUS Metadata Security for SharePoint allows organizations to leverage all of the benefits of user claims and document metadata to secure their sensitive information in SharePoint. It ensures that the right people are accessing the right information and it allows Microsoft SharePoint to implement Fail Safe Security so that sensitive information remains secure in all circumstances.

-Antonio

Claims Based Security in SharePoint 2010 with ADFSv2 – Part 1: Claim Rules

Previously, we’ve talked about how using trusted attributes of a user’s identity (or claims) along with document metadata is a very robust way of enforcing security policies within Microsoft SharePoint 2010. This article reviews another important tool that can be used to configure security policies for SharePoint:  Claim Rules.

In general, claim rules can be used to centrally evaluate, transform or augment claims before they are returned to a relying party application like SharePoint. Microsoft Active Directory Federation Services version 2.0 (ADFSv2) can act as a trusted identity provider to SharePoint and other relying party apps.  It provides a great interface with templates for creating and editing claim rules as part of its management console.  As well, it provides a ‘claim rule language’ that can be used to configure detailed policies with very specific conditions. This allows us to configure specific claims to be retrieved under very specific conditions, and thereby enforce very specific security policies for authentication and authorization.

This series of articles talks in detail about how to use this mechanism to enforce dynamic access control policies within SharePoint 2010 and, it illustrates how these policies relate to particular industries and regulations in SharePoint.

This article assumes an in-depth level of knowledge related to configuring SharePoint with Claims Based Authentication using ADFSv2.  For additional background on these topics please see the following article: An Architecture for Claims Based Authorization in SharePoint.

SharePoint 2010 can be configured to connect to a trusted identity provider like ADFSv2 to authenticate a user at sign-in time.  This is called Claims Based Authentication.  Under such a configuration, when a user signs into SharePoint, it will communicate with ADFSv2 passing it the user’s credentials.  ADFSv2 will then authenticate the user against Active Directory.  Before this happens, ADFSv2 will have been configured to trust the SharePoint 2010 server (the relying party) that is connecting and, as part of that trust relationship, ADFSv2 will have also been configured with 1 or more claim rules.  After the user is authenticated, ADFSv2 will apply the configured claim rules to the incoming claims in order to transform or augment them before they are issued and returned to SharePoint.

Configuring Claim Rules

ADFSv2 can be configured to accept incoming claims as well as issue outgoing claims.  In either case, trust needs to be configured between ADFSv2 and the calling app.  For incoming claims, the trust relationship in the ADFSv2 management console is referred to as the “Claims Provider Trust”.  For outgoing claims, or claims that ADFSv2 issues to a relying party, the trust relationship is referred to as the “Relying Party Trust”.  The important point here is that claim rules are configured as properties of these “trusts”.

ADFSv2 Management Console

ADFSv2 can be configured with one or more trusts (one for each calling application), and each trust can have one or more claim rules. When configuring a trust for SharePoint, you will need to provide the realm of the SharePoint server. ADFSv2 will use the realm passed to it in order to map a particular request to a particular trust that’s been configured.  For more information on configuring the realm, see the following:  Configuring the Realm for SharePoint 2010 and ADFSv2 to Retrieve Claims.

Once the trust is configured for the particular SharePoint server, to create a claim rule for that trust, perform the following steps:

• In the ADFSv2 Management Console, click Relying Party Trusts in the tree at the left side
• Right click on the particular trust which pertains to the SharePoint server you’re working with
• Click the Edit Claim Rules menu
• Ensure that you have the Issuance Transform Rules tab selected (the first tab)
• Click the Add Rule button and follow the instructions in the wizard – it is quite easy to use
• Keep in mind that the claim rules will be executed in the order listed. This can be important, especially if you have one claim rule acting on the claims issued by another rule. You can use the arrows on the right side of the Edit Claim rule window to change the order and get the desired output.

Once you’ve configure a set of claim rules for a particular trust, unfortunately they cannot be reused on another trust. If you must reuse the same claim rule(s) with more than one trust, you’ll need to manually recreate them. We’re focusing on enforcing security policies within SharePoint, so this particular article will focus only on claim rules configured for a Relying Party Trust which issues outgoing claims to SharePoint. From this point forward, the article will refer to SharePoint as the relying party, but please keep in mind that any relying party can be configured and used with the same types of claim rules.

Again, when a user signs into SharePoint, SharePoint will call its configured trusted identity provider, ADFSv2 in this case, and ADFSv2 will authenticate the user against its directory or database. Then ADFSv2 will execute the claim rules that have been configured with the particular trust for the calling SharePoint server. These particular claim rules will be used to determine which attributes are ultimately issued to (ie. returned) to SharePoint.

Claim Rule Templates

Claim rules will be used to determine which attributes are ultimately issued as outgoing claims (ie. returned) to SharePoint. These rules can be quite simple – for example, they can simply retrieve specific LDAP attributes from Active Directory and return them to the connecting SharePoint server as SAML claims. They can also be more complex, and we’ll see some examples of that later. The ADFSv2 management console provides 4 templates and an easy to use wizard for configuring rules. For many security policies, these templates are quite sufficient for achieving a policy’s intended purpose. These templates are:

1. Send LDAP Attributes as Claims

• Probably the simplest type of rule, it can be used to retrieve user attributes from an LDAP directory and issue them as outgoing claims to SharePoint.
• It can be used to perform a simple mapping of attributes if required, from an LDAP attribute name to perhaps a different name (or claim type) that SharePoint is expecting. For example, a claim rule could retrieve the standard LDAP attribute ‘organizationStatus’ and map it to the claim type ‘EmployeeStatus’ if that’s more appropriate for the intended user experience within SharePoint.
• Multiple claims can be retrieved or mapped with a single rule.
• Performance can be somewhat affected by this type of claim rule due to the account look up that must occur. However, for all practical purposes the performance impact appears to be minimal for each individual request.

2. Send Group Membership as a Claim

• This claim rule will check to determine if the user is a member of a specific AD group and if so, it will issue a specified claim with a specified value. This can be very helpful if you already have security groups in place and want to leverage them to enforce claims based authorization policies in SharePoint.
• The unfortunate thing about this template is that each rule will only check membership to 1 group. You can create multiple instances of this type of rule for the same trust, and within each rule check membership to a different group so that a particular claim is issued in each case. However, if you want to enforce policies where a user must belong to multiple groups in order to access content within SharePoint, then a more sophisticated solution is needed – Please see Part 3 of this blog series for an example of how to accomplish this with the Claim rule Language.
• As well, this claim rule does not support SharePoint groups, only Active Directory groups. To check membership to SharePoint groups, you must create a custom claims provider that runs on your SharePoint server… but that is for another day.
• One positive thing about this rule template is that it is very fast to execute. The reason is that one of the default claims that ADFSv2 retrieves is the list of all groups SIDs that a user belongs to. ADFSv2 does not need to do any additional account look up.
• This rule can only be used for users that authenticate locally using AD DS (Active Directory Domain Services) and come through ADFSv2 through the Active Directory Claims Provider Trust.

3. Transform an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can apply various actions to transform the type or value before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued with the same type and value.
• Another option is to modify the type of the claim before it is issued as an outgoing claim. So, for example, an incoming claim could be of type “OrgStatus” and this rule could be used to issue it as the outgoing claim type “Status”, keeping its current value. Another incoming claim in the same environment could be of type “OrganizationStatus” and a similar rule could issue it as the outgoing claim type “Status”, again keeping its current value. This type of rule can help to normalize claim types when they are coming from various sources and perhaps have differing claim type names, but all mean the same thing.
• Additional options in this rule template allow you to modify the value of the claim before it is issued. The following options are available:
  • If the value of an incoming claim equals a specified value, then change its value to a new specified value before issuing the outgoing claim. There are no StartsWith, EndsWith or Contains-like options available here. More complex value checking requires a custom claim rule – see Part 2 of this blog series.
  • If an incoming claim contains an email suffix, then replace it with a specified email suffix.

4. Pass Through or Filter an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can optionally apply other filters before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued.
• Another option is to filter it based on certain values. The following options are available for filtering:
  • Only issue the claim if its value equals a specified value – for example, if an incoming claim is of type ‘EmployeeStatus’ and if its value is ‘Full Time’. The claim is issued only if both conditions are met.
  • Only issue the claim if it is an email address and if it ends in a particular value – for example, check if the claim type is E-Mail Address, and if so issue it only if the email suffix is ‘titus.com’ or some partner email domain.
  • Only issue the claim if its value starts with a particular string – for example, check if the claim type is Department and if its value starts with certain department acronym.
• Claim values cannot be changed with this type of rule. They must either be issued or not based on their type and value.
• This rule can apply to claims that have been issued by previous rules. One interesting use for this type of rule is if certain claim types contain sensitive information and you do not want that information to be issued to certain relying parties. The issuing of certain outgoing claims can then be restricted based on their values.

Once a user has signed in and their claims are retrieved, SharePoint 2010 does a great job of enforcing permissions on documents and items to which claims have been assigned with a permission level. Of course a user must have those claims as part of their identity to gain access to a document or item with the assigned permission level. Centrally managing how claims are retrieve and returned through ADFSv2 claim rules can allow you to implement some very robust access control policies in SharePoint. Applying those claims with permission levels to documents and items in SharePoint is still a manual and labor intensive task that can be very error prone – for more information on how the TITUS SharePoint Security Suite can automatically assign such access control policies at a fine grained level in SharePoint please read the white paper Microsoft SharePoint Security – Harness the power of claims to protect information or check out the video.

Once again, for many security policies these rule templates are sufficient for achieving a policy’s intended purpose. If more sophisticated policies are required, ADFSv2 does provide a Claim Rule Language that can be used to author detailed policies with very specific conditions. Please see Part 2 of this blog series in order to learn more about how to use the Claim Rule Language.

-Antonio