Microsoft IT implements a custom claims provider (case study)

  • Article

 

Applies to: SharePoint Server 2010

Microsoft IT (MSIT) successfully designed and implemented a claims-based security model using Microsoft SharePoint Server 2010 for an internal human resources portal.

In this article

  • A flexible security model

  • SharePoint claims

  • Components of the human resources portal security model

  • Additional resources

A flexible security model

The human resources portal supports about 90,000 unique identities using a custom claims provider to implement compound claims and claims augmentation. By default, SharePoint Server 2010 supports simple, disjunctive claims that can only use the OR operator between assertions. To use compound claims that are conjunctive and disjunctive (supporting the use of the OR and AND operators between assertions), a custom claims provider is required. Claims augmentation was also a requirement to enable the combination of user data from an internally accessible data repository (Active Directory Domain Services) with information from external data repositories such as SAP. The custom claims provider was designed to explicitly secure and target specific content to each uniquely identified user. The custom claims provider was also required to support a feature called View Portal As. View Portal As enables the temporary delegation of one user’s identity to another user. This allows the user with the delegated identity to view the human resources portal as another user. The View Portal As feature is restricted to a subset of administrators who are working on the human resources portal, and is not available to most users who can access the portal.

SharePoint claims

SharePoint Server 2010 provides the benefits of simple claims-based authentication, which includes a secure identity management system that enables the configuration and management of user authentication, authorization, and auditing. Claims are made up of identity assertions that are encapsulated in security tokens that are granted to authenticated users, which enable users to access resources within SharePoint Server 2010 Web applications. Identity assertions are attributes that are associated with users. Assertions can include a user name, a role, an employee ID, and a variety of other attributes that can be used to determine authorization and permission levels for access to SharePoint Server 2010 Web application resources. Security tokens are created and managed by a Security Token Service (STS) that acts as an identity provider. An STS encapsulates a collection of assertions, based on attributes specified by a policy, into a security token that can then be used to authenticate and authorize a user. To create a security token, the STS must be able to locate valid credentials for a user in an attribute store. Active Directory Domain Services can be used as an attribute store for an STS.

Components of the human resources portal security model

To provide manageable, searchable, and secure access for about 90,000 users, the design of the human resources portal includes the implementation of the following components:

  • SharePoint groups

  • Audience targeting

  • FAST Search

SharePoint groups

To manage a deployment that includes about 90,000 users and an implementation that has to handle hundreds of compound claims, the design of the security model for the human resources portal includes SharePoint groups. A SharePoint group is a logical container for SharePoint Server 2010 users. By implementing SharePoint groups, administrators can create meaningful group names to identity collections of claim values. In addition, People Picker supports name resolution for SharePoint groups. Another reason to implement SharePoint groups is that SharePoint groups enable administrators to dynamically manage authentication and the use of the OR operator to combine multiple claims at the level of a SharePoint group.

Audience targeting

Enabling administrators to filter and scope content for specified groups of users is important in a deployment that supports about 90,000 users. The human resources portal design team used the User Profile Service Application to implement SharePoint groups for audience targeting. However, when the design team created a SharePoint group that contains claims from a custom claims provider, the design team did not assign a default permission level to the SharePoint group. When you create SharePoint groups, use the groups for security, and do not assign a permission level when you create them, the groups are automatically assigned a Limited Access permission level. The target audience processor ignores SharePoint groups that are created in this way. To resolve this issue, the design team discovered that if it assigned the Read level permission to a SharePoint group that contains claims from a custom claims provider, and then removed the Read level permission, the target audience processor correctly processed the SharePoint group. You only need to perform this procedure on one SharePoint group within the inheritance tree. You do not need to perform this procedure on every SharePoint group that contains a claim from a custom claims provider.

To provide content discoverability and a high level of search performance across a deployment that includes a very large number of users and network resources, the portal design team used Microsoft FAST Search Server 2010 for SharePoint hosted in a federated environment. The FAST Search Server 2010 for SharePoint deployment included the following components:

  • Query Search Service Applications

  • A content Search Service Application

  • A content source

The design team learned that custom claim type mappings must be registered in the FAST Search Server 2010 for SharePoint farm to enable search security trimming, and that any custom claims provider used in the human resources portal must also be deployed in the FAST Search Server 2010 for SharePoint farm. The design team also learned that you must confirm that the claim type mappings are registered, and that all claim IDs are the same across all of the SharePoint Server 2010 farms for the same claim type value pair. In addition, the design team learned that the following conditions must be met to ensure that the human resources portal is searchable from other intranet portals within the enterprise:

  • All other intranet portals that render human resources portal content are built on SharePoint Server 2010 and use claims-based Web applications and the Windows authentication method.

  • All other intranet portals that render content from the human resources portal are querying the same FAST Search index.

  • All other intranet portals that render content from the human resources portal have the custom claims provider for the human resources portal installed. Also, the custom claims provider must be installed in the same sequence as it was installed on the human resources portal.

The following diagram illustrates the physical architecture for the MSIT human resources portal built on SharePoint Server 2010 and FAST Search Server 2010 for SharePoint, using a custom claims provider.

MSIT SharePoint claims network diagram

Additional resources

For more detailed information about implementing this deployment scenario, see Custom Claims-Based Security in SharePoint 2010 (https://go.microsoft.com/fwlink/p/?LinkId=232558).

SharePoint Server 2010 claims-based authentication is built on the Windows Identity Foundation (WIF), which is a set of .NET Framework classes. Claims-based authentication relies on standards such as WS-Federation and WS-Trust. For more information about WIF, see Windows Identity Foundation Simplifies User Access for Developers (https://go.microsoft.com/fwlink/p/?LinkId=198943).

For prescriptive guidance about how to implement a custom claims provider, see the following TechNet and MSDN articles: