Incoming Claims: Signing into SharePoint

SharePoint 2010

Last modified: June 28, 2011

Applies to: SharePoint Foundation 2010

When a user signs in to Microsoft SharePoint Foundation 2010 or Microsoft SharePoint Server 2010, the user's token is validated and then used to sign in to SharePoint. The user's token is a security token issued by a claims provider.

Note Note

For information about claims authentication for a single SharePoint farm and inter-farm SharePoint claims authentication, see Plan for Claims Authentication on TechNet.

Windows Classic Mode Sign-In

The Windows classic mode sign-in is similar to Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 Windows authentication sign-in. In Windows classic mode sign-in, the sign-in happens with the Integrated Windows authentication challenge by using Negotiate (NTLM/Kerberos). No claims augmentation is done, so some features (for example, multitenant support for service applications and custom claims providers) in SharePoint Foundation 2010 and SharePoint Server 2010 do not work when a user signs in by using this mode.

Some service applications may also require claims mode for some features. For more information about service applications requirements, see Service Application Framework Architecture.

Windows Claims Mode Sign-In

In Windows claims mode sign-in, the sign-in happens with Integrated Windows authentication challenge by using Negotiate (NTLM/Kerberos). However, after the WindowsIdentity object (which represents a Windows user) is created, SharePoint Foundation 2010 converts the WindowsIdentity object into a ClaimsIdentity object (which represents a claims-based representation of a user).

SharePoint Foundation 2010 then does claims augmentation and handles the resulting token that is issued by SharePoint Foundation 2010. This means that the new features (for example, multitenant support for service applications and custom claims providers) in SharePoint Foundation 2010 and SharePoint Server 2010 work, even though the clients believe that SharePoint Foundation 2010 is in native Windows login mode. The Windows claims-mode sign-in experience is the built-in default for SharePoint Server 2010.

All claims sign-in types rely on passive sign-in. The passive sign-in happens by using Windows challenge, but from a separate login page that arrives through a 302 redirect. This mode is useful when more than one sign-in method is turned on and the user must choose between the supported claims providers. Win32 clients must support the forms-based authentication that is implemented in Microsoft Office clients. Some Office clients follow a different protocol.

For more information about passive sign-in, see in the following section entitled SAML Passive Sign-in Mode.

SAML Passive Sign-in Mode

In Security Assertion Markup Language (SAML) passive sign-in, when a user signs in, the client (which might be a Web page) is redirected to the designated claims provider (for example, the Windows Live ID claims provider). After the claims provider authenticates the user, SharePoint Foundation 2010 takes the SAML token presented by the claims provider, processes the SAML token, and then augments the claims.

For SAML-based claims providers, like the Active Directory Federation Services (ADFS) claims provider and the Windows Live ID claims provider, signing in by using the SAML passive sign-in mode is the only supported way. The SAML passive sign-in is the SharePoint online identity model.  

Note Note

SAML passive sign-in describes the process of signing in. When a sign-in for a Web application is configured to accept tokens from a trusted login provider, this type of sign-in is called SAML passive sign-in.  A trusted login provider is an external (that is, external to SharePoint) security token service (STS) that SharePoint trusts.

Win32 clients must support the forms-based authentication that is implemented in Office clients.

ASP.NET Membership and Role Passive Sign-In

In ASP.NET membership and role passive sign-in, the sign-in happens by redirecting the client to a Web page where the ASP.NET log-in controls are hosted. After the identity object that represents a user identity is created, SharePoint Foundation 2010 converts it to a ClaimsIdentity object (which represents a claims-based representation of a user).

SharePoint Foundation 2010 then does claims augmentation. Win32 clients must support the forms-based authentication that is implemented in Office clients.

Anonymous Access

You can enable anonymous access for a Web application. Administrators of sites within the Web application can choose to allow anonymous access. If anonymous users want to gain access to secured resources, they can click a logon button to submit their credentials.

SharePoint Foundation 2010 then does claims augmentation. Win32 clients must support the forms-based authentication that is implemented in Office clients.

Show: