Compartir a través de

Appendix F

  • Artículo
Benefits of a Claims-Based Architecture - Windows Identity Framework | Implementation of the Claims-Based Architecture - SharePoint 2010 User Identity, The SharePoint 2010 Security Token Service, The SharePoint 2010 Services Application Framework | Considerations When Using Claims with SharePoint - Choosing an Authentication Mode, Supported Standards, Using Multiple Authentication Mechanisms, SharePoint Groups with Claims Authentication, SharePoint Profiles and Audiences with Claims Authentication, Rich Client, Office, and Reporting Applications with Claims Authentication, Other Trade-offs and Limitations for Claims Authentication | Configuring SharePoint to Use Claims | Tips for Configuring Claims in SharePoint | More Information

Download code samples

Download PDF

Download Paperback

This appendix provides background information about the way that Microsoft® SharePoint® 2010 implements claims-based authentication. This is a major change to the authentication architecture compared to previous versions, and makes it easier to take advantage of federated authentication approaches for SharePoint websites, applications, and services. It also contains information on some of the important factors you should consider when creating and deploying claims-aware SharePoint applications and services.

Versions prior to SharePoint 2010 use the techniques for authentication provided by the Microsoft Windows® operating system and ASP.NET. Applications can use Windows authentication (with the credentials validated by Microsoft Active Directory® directory service), ASP.NET forms authentication (with credentials typically validated from a database), or a combination of these techniques.

To make claims-based and federated authentication easier, SharePoint 2010 can use a claims-based model for authentication. This model still fully supports Windows and forms authentication, but does so by integrating these approaches with the claims-based authentication mechanism. This appendix provides background information that will help you to understand how this model is implemented within SharePoint 2010.

Benefits of a Claims-Based Architecture

Users often require access to a number of different applications to perform daily tasks, and increasingly these applications are remotely located so that users access them over the Internet. ASP.NET forms authentication typically requires the maintenance of a separate user database at each location. Users must have accounts registered with all of the Active Directory domains, or in all of the ASP.NET forms authentication databases.

The use of tokens and claims can simplify authentication by allowing the use of federated identity—users are authenticated by an identity provider that the organization and application trusts. This may be an identity provider within the organization, such as Active Directory Federation Services (ADFS), or a third party (a business partner or a social identity provider such as Windows Live® or Google).

As well as simplifying administration tasks, claims-based authentication also assists users because it makes it possible for users to use the same account (the same credentials) to access multiple applications and services in remote locations, hosted by different organizations. This allows for single sign-on (SSO) in that users can move from one application to another, or make use of other services, without needing to log on each time.

The integration of claims-based authentication with the existing architecture of SharePoint provides the following benefits:

  • Support for single sign-on over the Internet in addition to the existing location-dependent mechanisms such as Active Directory, LDAP, and databases.
  • Automatic and secure delegation of identity between applications and between machines in a server farm.
  • Support for multiple different authentication mechanisms in a single web application without requiring the use of zones.
  • Access to external web services without requiring the user to provide additional credentials.
  • Support for standard authentication methods increasingly being used on the web.
  • Support for accessing non-claims-based services that use only Windows authentication.

Windows Identity Framework

SharePoint 2010 uses the Windows Identity Framework (WIF) for authentication irrespective of the authentication approach used by the individual applications and services. This is a fundamental change in the architecture of SharePoint in comparison to previous versions. WIF is a standards-based technology for working with authentication tokens and claims, and for interacting with security token services (STSs). It provides a unified programming model that supports both the Passive and Active authentication sequences.

Note

The Passive authentication sequence uses the WS-Federation protocol for authentication in web browser-based scenarios, such as ASP.NET applications. It depends on redirection of the browser between the relying party, token issuers, and identity providers.
The Active authentication sequence uses the WS-Trust protocol for authentication in web service scenarios, such as Windows Communication Foundation (WCF) services. The service "knows" (typically through configuration) how to obtain the tokens it requires to access other services.

Implementation of the Claims-Based Architecture

The claims-based architecture in SharePoint 2010 comprises three main themes and the associated framework implementations. These three themes correspond to the three main factors in the flow of identity through SharePoint applications and services.

  • The first theme is the extension of authentication to enable the use of multiple authentication mechanisms. Authentication is possible using tokens containing claims, ASP.NET forms authentication, and Windows authentication. External authentication is implemented though an STS within SharePoint 2010.
  • The second theme is identity normalization, where the identity verified by the different authentication mechanisms is converted to an IClaimPrincipal instance that the Windows Identity Framework authorization mechanism can use to implement access control.
  • The third theme is supporting existing identity infrastructure, where the identity can be used to access external services and applications that may or may not be claims-aware. For non-claims-aware applications and services, WIF can generate an IPrincipal instance to allow other authentication methods (such as Windows authentication) to be used even when the original identity was validated using claims. This is implemented though the Services Application Framework within SharePoint 2010.

Figure 1 shows a conceptual overview of these three themes, and the mechanisms that implement them in SharePoint 2010.

Hh446523.1ae7a0f9-e17e-4256-ad23-c57b735df7c4-thumb(en-us,PandP.10).png

Figure 1

The three authentication themes in SharePoint 2010

SharePoint 2010 User Identity

Internally, SharePoint 2010 uses the SPUser type to manage and flow identity through applications and services. The fundamental change in this version of SharePoint compared to previous versions is the provision of an external authentication mechanism that supports identity verification using claims, as well as ASP.NET forms and Windows authentication. The external authentication mechanism converts claims it receives into a SAML token, then maps this token to an instance of the SPUser type.

The claims may be received in the form of a SAML token from ADFS, Microsoft Azure™ AppFabric Access Control Service (ACS), or another STS; as a Windows NT token; or from the ASP.NET forms authentication mechanism. An application can be configured to use more than one authentication mechanism, allowing users to be authenticated by any of the configured mechanisms.

Note

Previous to version 2010, supporting more than one authentication method for a SharePoint application typically required the use of zones; each of which is effectively a separate Microsoft Internet Information Services (IIS) web site and URL pointing to the application. Zones are no longer required in SharePoint 2010 because applications can be configured to use a combination of authentication methods, although they can still be used if required (for example, if a different application URL is required for each authentication method).

It is also possible to configure the SharePoint 2010 authentication mechanism in "Classic" mode for existing applications or services that are not claims-aware, and which present a Windows NT token that SharePoint can map to an instance of the SPUser type. If you select classic mode, you can use Windows authentication in the same way as in previous versions of SharePoint, and the user accounts are treated as Active Directory Domain Services (AD DS) accounts. However, services and service applications will use claims-based identities for inter-farm communication regardless of the mode that is selected for web applications and users.

Figure 2 shows an overview of the sign-in methods supported by the SharePoint 2010 authentication mechanism.

Hh446523.092cb1b4-c46d-469b-8cda-2f91560c9f9f-thumb(en-us,PandP.10).png

Figure 2

Authentication methods in SharePoint 2010

Note

Windows certificate-based authentication is not supported by the SharePoint 2010 claims-based authentication mechanism.

The SharePoint 2010 Security Token Service

The conversion of claims received in the different formats is carried out by an STS within SharePoint 2010. This is a fairly simple STS that can map incoming claims to the claims required by the relying party (the target application or service). It can also be configured to trust external STSs such as ADFS, ACS, and other token issuers.

Applications and services running within SharePoint 2010 access the local SharePoint STS to discover the claims for each user or process that requires authorization. For example, applications can verify that the current user is a member of one of the required Active Directory groups. This is done using the WIF authorization mechanisms, and works in much the same way as (non-SharePoint) applications that access ADFS or ACS directly to obtain a token containing the claims.

For example, when a user accesses a SharePoint-hosted ASP.NET application that requires authentication, the request is redirected to an identity provider such as ADFS or ACS. The token received from the identity provider is then posted to the SharePoint STS (which the application must be configured to trust). The SharePoint STS authenticates the user and augments (transforms) the claims in the token or request. It then redirects the request back to the application with the augmented claims. Inside the application, the claims can be used to authorize the user for specific actions. Figure 3 shows this process.

Hh446523.2ff7e298-6d7e-4b69-8508-02dd97702019-thumb(en-us,PandP.10).png

Figure 3

Claims authentication sequence in SharePoint 2010

The SharePoint 2010 Services Application Framework

One of the typical scenarios for a SharePoint application is to access both internal (SharePoint hosted) and external services to obtain data required by the application. Internal services include the Search Service, Secure Store Service, Excel Services, and others. External services may be any that expose data, either on a corporate network or from a remote location over the Internet.

Accessing these services will, in most cases, require the application to present appropriate credentials to the services. In some cases, the services will be claims-aware and the application can present a SAML token containing the required claims. As long as the external service trusts the SharePoint STS, it can verify the claims.

Some services may not, however, be claims aware. A typical example is when accessing a Microsoft SQL Server® database. In these cases, the SharePoint Services Application Framework can be used to generate a Windows token that the application can present to the service. This is done using the Claims to Windows Token Service (C2WTS), which can create a suitable Windows NT token.

Note

Microsoft Visual Studio® development system provides support and features to make building and deploying SharePoint 2010 applications easier. This support is included in all editions of Visual Studio 2010 (Professional, Premium, and Ultimate). It is not available in the Express versions of Visual Studio.

Considerations When Using Claims with SharePoint

The following sections provide specific guidance on topics related to using claims authentication in SharePoint 2010 applications and services.

Choosing an Authentication Mode

Claims-based authentication is now the recommended mechanism for SharePoint, and all new SharePoint applications should use claims-based authentication; even if the operating environment will include only Windows accounts. SharePoint 2010 implements Windows authentication in the same way regardless of the mode that is selected, and there are no additional steps required to implement Windows authentication with the claims-based authentication mode.

If you are upgrading an application that uses ASP.NET forms-based authentication, you must use claims-based authentication. Classic mode authentication cannot support ASP.NET forms-based authentication.

The only scenario where choosing classic mode authentication is valid is when upgrading to SharePoint 2010 and existing accounts use only Windows authentication. This allows existing applications to continue to operate in the same way as in previous versions of SharePoint.

Note

The default authentication mode for a new SharePoint application is classic mode. You must specifically select claims-based authentication mode when creating a new application or website.

Supported Standards

SharePoint 2010 supports the following claims-related standards:

  • WS-Federation version 1.1
  • WS-Trust version 1.4
  • SAML Tokens version 1.1

SharePoint 2010 does not support SAML Protocol (SAMLP).

Using Multiple Authentication Mechanisms

When multiple authentication methods are configured for an application, SharePoint displays a home realm discovery page that lists the authentication methods available. The user must select the method to use. This adds an extra step into the authentication process for the user. It is possible to create a custom home realm discovery (sign-in) page if required.

SharePoint 2010 does not discriminate between user accounts when different authentication methods are used. Users that successfully authenticate with SharePoint 2010 using any of the claims-based authentication methods have access to the same resources and services as would be available if that user was authenticated using classic Windows authentication.

Users who access a SharePoint 2010 application that is configured to use claims-based authentication and has multiple authentication methods set up will have the same access to resources and services when using any of the authentication methods. However, if the user has two different accounts configured (in other words, has accounts in two different repositories, such as a social identity provider and ASP.NET), and the authentication method used validates the user against one of these accounts, the user will have access to only resources and services configured for the account that was validated.

You can configure multiple SAML authentication providers for a server farm and application. However, you can configure only a single instance of an ASP.NET forms-based authentication provider. If you configure Windows authentication when using claims-based authentication mode, you can use both a Windows integrated method and a Basic method, but you cannot configure any additional Windows authentication methods.

Note

For a discussion on the merits of using multiple identity providers for authentication, see Chapter 12 of this guide, "Federated Identity for SharePoint Applications."

SharePoint Groups with Claims Authentication

To simplify administration tasks when setting authorization permissions on resources, it is recommended that you use SharePoint Groups. Setting permissions for resources based on membership of a specific group means that it is not necessary to continually update the permissions as new users are added to groups or existing users are removed from groups.

The SharePoint STS automatically augments the claims in the tokens it issues to include group membership for users when Windows authentication is used. It also automatically augments the tokens to include the roles specified for users when ASP.NET forms-based authentication is used; with each role translated into a SharePoint group name (the SharePoint groups are not created automatically).

When using SAML tokens issued by external identity providers and STSs, you must create a custom claims provider that augments the tokens to include the relevant roles. For example, you could create a custom claims provider that augments the SharePoint STS token with specific roles based on a test of the claims in the token received from the identity provider. This may be done by checking the incoming token to see if it was issued by a specific partner's STS, or that the email address is within with a specific domain.

SharePoint Profiles and Audiences with Claims Authentication

SharePoint user profiles are not populated automatically when using claims-based authentication methods. You must create and populate these profiles yourself, typically in code. Users that map to existing accounts when you migrate to claims-based authentication will use any existing profile information, but other users and new users will not have profile information. For information about how you can populate user profiles when using claims-based authentication, see "Trusted Identity Providers & User Profile Synchronization" at https://blogs.msdn.com/b/brporter/archive/2010/07/19/trusted-identity-providers-amp-user-profile-synchronization.aspx.

The same limitation occurs when using SharePoint Audiences. You cannot use user-based audiences directly unless you create custom code to support this, but you can use property-based audiences that make use of claims values. For information, see "Using Audiences with Claims Auth Sites in SharePoint 2010" at https://blogs.technet.com/b/speschka/archive/2010/06/12/using-audiences-with-claims-auth-sites-in-sharepoint-2010.aspx.

Rich Client, Office, and Reporting Applications with Claims Authentication

Claims-based authentication methods in SharePoint support almost all of the capabilities for integration with Office client applications and services. Office 2007 clients can use forms-based authentication to access SharePoint 2010 applications that are configured to use forms-based authentication and Office 2010 clients can use claims to access SharePoint 2010 applications that are configured to use claims-based forms-based authentication. However, there are some limitations when using claims-based authentication:

  • Microsoft Office Excel® Services can use only the Classic or the Windows claims-based authentication methods. When using other claims-based authentication methods you must use the Secure Store Service for external data connections and unattended data refresh.
  • Microsoft Visio® Services can use the Secure Store Service, but only for drawings that use an Office Data Connection (ODC) file to specify the connection. The Unattended Service Account option can also be used with the same limitation.
  • PowerPivot can be used in workbooks with embedded data, but data refresh from a data source is not possible when using any of the claims-based authentication methods.
  • SQL Server 2008 R2 Reporting Services integration is only possible when using classic Windows Authentication. It cannot use the Claims to Windows Token Service (c2WTS), which is a feature of Windows Identity Foundation.
  • PerformancePoint must use the Unattended Service Account option in conjunction with Secure Store Service when using claims-based authentication.
  • Project Server maintains a separate user database containing logon information, and so migrating users when using claims-based authentication is not sufficient.

Other Trade-offs and Limitations for Claims Authentication

When upgrading existing applications to SharePoint 2010, be aware of the following factors that may affect your choice of authentication type:

  • Claims-based authentication requires communication over HTTPS with a token issuer and identity provider. It typically also requires multiple redirects for clients that are using a web browser. These are likely to be slower than Windows Authentication or ASP.NET forms-based authentication lookup. Even after initial authentication, as users move between applications taking advantage of single sign-on, the applications and services must make calls over HTTPS to validate the authentication tokens.
  • Web Parts or custom code that relies on or uses Windows identities must be modified if you choose claims-based authentication. Consider choosing classic mode authentication until all custom code is updated.
  • When you upgrade a web application from classic mode to claims-based authentication, you must use Windows PowerShell® command-line interface to convert Windows identities to claims identities. This can take time, and you must factor in time for this operation as part of the upgrade process.
  • Search alerts are currently not supported with claims-based authentication.
  • You cannot use custom ISAPI extensions or HTTP modules with the forms-based authentication method because the SharePoint STS communicates directly with the forms authentication provider by calling its ValidateUser method.
  • Some client-hosted applications may attempt to authenticate with the server when displaying content linked from SharePoint application web pages. If you are using claims-based authentication and the client-hosted application is not claims-aware (as in the case of Windows Media Player), this content might not be displayed.
  • Managing the session lifetime is not a trivial exercise when using claims-based authentication. For details of how you can manage session lifetime, see Chapter 11, "Claims-Based Single Sign-On for Microsoft SharePoint 2010."
  • The External Content Type Designer in SharePoint Designer 2010 cannot discover claims aware WSDL endpoints. For more information, see MSDN® Knowledge Base article 982268 at https://support.microsoft.com/default.aspx?scid=kb;EN-US;982268.

Note

Applications are not changed to claims-based authentication mode automatically when you upgrade to SharePoint 2010. If you later convert an application from classic authentication mode to claims-based authentication mode, you cannot convert it back to classic authentication mode.

Claims-based authentication validates users from a variety of realms and domains, some of which do not provide the wealth of information about users that is available from Windows authentication against Active Directory. This has some impact on the usability of SharePoint in terms of administration and development.

Primarily, the People Picker user experience is different when using claims-based authentication. It does not provide the same level of support, such as browsing repositories (lists of accounts are not stored or available in the people picker). This means that locating accounts involves using the search feature against known attributes. However, the people picker UI does provide some assistance using pop-up tool tips. Alternatively, you can create a custom implementation of the SPClaimProvider class to extend the people picker and provide an enhanced user experience.

Administrators must also configure and manage the SharePoint STS to implement the appropriate trust relationships and the rules for augmenting claims. This can only be done using PowerShell. In addition, the order for configuring items and the provision of the correct claim types is critical.

The SharePoint STS is fairly simple compared to an STS such as ADFS or ACS, and basically implements only rules for copying claims. It requires the STSs and identity providers it trusts to implement the appropriate claims. It also runs in the same domain as SharePoint, and the FedAuth cookies it exposes are scoped to that domain. It does provide a token cache.

You may need to configure a SharePoint server farm to use affinity for web applications to ensure that users are directed to the server on which they were authenticated. If users are authenticated on more than one server, the token may be rejected in a subsequent request, and the continual re-authentication requests may resemble a denial-of-service attack that causes the identity provider or STS to block authentication requests.

Configuring SharePoint to Use Claims

Many configuration tasks in SharePoint, especially when configuring a SharePoint server farm, are performed using Windows PowerShell commands and scripts. Many of the required scripts are provided with SharePoint or are available for download from the SharePoint resource sites listed at the end of this appendix.

The main tasks for configuring SharePoint web applications to use claims are the following:

  • Configure an identity provider STS web application using PowerShell
  • Configure a relying party STS web application
  • Establish a trust relationship with an identity provider STS using PowerShell
  • Export the trusted identity provider STS certificate using PowerShell
  • Define a unique identifier for claims mapping using PowerShell
  • Create a new SharePoint web application and configure it to use SAML sign-in

The following resources provide step-by-step guides to setting up claims authentication for a web application in SharePoint:

Tips for Configuring Claims in SharePoint

The following advice may be useful in resolving issues encountered when configuring a SharePoint application to use claims authentication:

  • The SharePoint PowerShell snap-in requires developers and administrators to have special permissions in the SharePoint database. It is not sufficient just to be an administrator or a domain administrator. For information on how to configure the SharePoint database for the PowerShell snap-in, see "The local farm is not accessible Cmdlets with FeatureDependencyId are not registered" at http://www.sharepointassist.com/2010/01/29/the-local-farm-is-not-accessible-cmdlets-with-featuredependencyid-are-not-registered/.
  • When you use ADFS 2.0, the setting for enabling single sign-on (SSO) is not available in the ADFS management interface. By default SSO is enabled. You can change the setting by editing the Web.config file for the ADFS website. The element to modify is <singlesignon enabled ="true" />. It is located in the microsoft.identityserver.web section.
  • When you create a new web application and configure it to work over HTTPS, you must edit the website bindings. This cannot be done in the SharePoint management tools. Instead, you must select the SSL certificate to use for the website in the IIS Manager Microsoft Management Console (MMC) snap-in.
  • It is possible to create more than one SharePoint application with the same alias, although this is generally unlikely. However, the authentication cookie served by the application uses the alias as the cookie name. The result is that single sign-on authentication will fail when users access one of the applications if they have previously accessed another application with the same alias because the authentication cookie is not valid for the second application. To resolve this, create each application under a different domain name and use DNS to point to the SharePoint application, or modify the cookieHandler element in the federatedAuthentication section of Web.config for each application to specify a different cookie name.

More Information

For more information about SharePoint 2010, see the following resources:

Next | Home