Considerations When Using Claims with SharePoint


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.

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 ValidateUsermethod.
  • 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 Link

No comments:

Post a Comment