Understanding SharePoint 2010 Claims Authentication

jokerchu

　　from:http://blogs.msdn.com/b/russmax/archive/2010/05/27/understanding-sharepoint-2010-claims-authentication.aspx
　　Claims
　　An identity provider makes claims about a user. A good example of an identity provider is Live ID. So Live ID will claim to have attributes and their values. For Example:
　　Identity Provider "provider of the attributes" contains username attribute containing DanCan. A custom identity provider created by a hacker also contains an account with username attribute named DanCan. Both identity providers are making claims about a user. The consumer "SharePoint 2010" must choose which claim it's going to trust. SharePoint 2010 by itself will never trust either claim without being told to do so. In order for SharePoint to use a claim, it must first trust that claim which is setup by you the SharePoint administrator. If claims are trusted, then SharePoint can authenticate and authorize over that claim.
　　
　　
　　
　　STS
　　STS is built on Geneva framework which is now called Windows Identity Foundation. The STS (Security Token Service) core responsibility is issuing, managing, and validating security tokens. An STS resides on both an identity provider and SharePoint. STS is built on top of the shared services framework which is why it's listed as a service application within Central Administrator\Manage Service Applications page:


　　Above, STS is composed of a web service and runs on every SharePoint server.
　　Authentication
　　The authentication type is setup at the Web Application level when creating a new SharePoint web application. It's possible to choose either classic authentication or Claims authentication. Each one is discussed below:
　　
　　Classic
　　Active Directory authenticates a user, provides an NT Token. The token is used to authenticate to SharePoint. SharePoint consumes that token and it's converted into an SPUser object for authorization.
　　Note: Authorization is the process of determining what level of access an authenticated user has to a secured resource such as a Site, Document library etc.. The authorization mechanism hasn't changed in SharePoint 2010 and we ultimately still use an SPUser object to authorize.
　　
　　
　　Claims
　　After a trust is established between SharePoint and an Identity provider, web applications can be set with Claims authentication type instead of classic. If a client attempts to authenticate to a claims aware web application, SharePoint redirects a client to the associated trusted identity provider. The identity provider authenticates clients and provides a security token. That token could be either of the following:
　　· NT Token
　　· SAML Token
　　This security token is this passed to SharePoint STS. In short, the STS will validate the token "Claims Based Identity" and generate a new security "SAML" token back to the client. This token is generated by SharePoint and for SharePoint. The client sends this SAML token to SharePoint to prove that he/she is officially authenticated. SharePoint validates and authenticates user and an SPUser object is created and is used for authorization.
　　
　　Steps for Claims Sign-In:
　　1. Client hit SharePoint site via HTTP (Get)   
2. SharePoint redirects client to Identity Provider in order to get a security token   
3. Client attempts to authenticate to trusted Identity Provider   
4. The identity provider's (Security Token Service) will validate the username and password and provide a security token to a client.
　　Note: A security token could be a Windows NT Token, SAML token, or FBA token
　　5. The client has a security token (authenticated) and submits it to SharePoint STS "Security Token Service"   
6. SharePoint STS receives security token from client and determines if we trust the issuer of that token "Identity Provider"   
7. STS then performs claims augmentation   
8. STS issues client new SAML token   
9. Client request resource "site" with new SAML token   
10. SharePoint consumes SAML token, "validates authentication successful", and builds an SPUser object in order to authorize to the secured resource
　　
　　Mixed Authentication
　　In SharePoint 2007, to use additional authentication provider, you had to extend the web application and drop it in a different zone so it would contain a different URL. SharePoint 2007 wasn't flexible in terms of specifying multiple authentication types in a single un-extended web application.
　　
　　
　　Multi Authentication
　　In SharePoint 2010, it's possible to configure multiple authentication types for a single web application. This provides 2 benefits:
　　1. No longer required to extend web-application for the purpose of adding additional authentication types
　　2. Can have a single web application use multiple authentication types which provides the ability to serve a single URL!
　　

　　
　　Note: You can still extend web-applications and assign one or more authentication types to it if a business justification calls for that.
　　
　　
　　
　　FBA
　　FBA users no longer uses an ASP.Net identity. FBA is now claims aware and the SharePoint STS facilitates the authentication process. Once user is authenticated, the SharePoint STS provides a SAML token to the client.
　　Note: When creating a web application designated for FBA, you must specify claims authentication type.
　　STS (federated equivalent of a domain controller) "issues tokens"
　　Basic FBA Sign-in process:
　　1. User signs in via FBA with credentials   
2. SharePoint STS calls membership provider to authenticate   
3. SharePoint STS calls role provider to get all the roles for the user   
4. Post successful authentication, a SAML token is generated by the SharePoint STS and passed back to the user   
5. The user then authenticates to SharePoint with SAML token and authentication is officially completed
　　For setup steps, please see my blog for more details.
　　
　　
　　
　　
　　
　　
　　
　　How Claims works with Services
　　
　　Accessing Internal Services
　　Within a Single Farm:
　　The classic example is a user performing a search. The WFE's (Server1) search web part talks to service application proxy. The associated search service application proxy calls the local STS to get a SAML token for the user. Once SAML token is collected, the search service application proxy then calls a server running the Query Processor via WCF call. I'll call this server, "Server 2". Server 2 receives the incoming request and validates the SAML token against its local STS. Once validated, Server 2 connects to various components to gather, merge, and security trims search results. Server 2 sends the trimmed search results back to Server 1 which are then presented to the user.
　　
　　Accessing External Services
　　SharePoint 2010 STS can manipulate a SAML token in order to present it to an external web service. The way it presents the identity depends on the type of external web service. The goal is preventing the additional prompt for credentials so that a full Single Sign-On (SSO) experience is possible. The STS is comprised of the WIF "Windows Identity Framework" and also the C2WTS. Each component is used dependent upon the type of external service accessed.
　　
　　
　　C2WTS = Claims to Windows Token Service
　　If accessing a native windows application that expects a Kerberos ticket. Within SharePoint STS, we use C2WTS to use existing SAML token in order to create a windows token (Kerberos ticket) to authenticate.
　　http://msdn.microsoft.com/en-us/library/ee517278.aspx
　　
　　SharePoint STS
　　Can be used to just issue SAML token to pass to external systems that support SAML tokens
　　Secure Store Service
　　SharePoint can be used to connect to a legacy LOB systems which requires credentials. (SSS) Captures credentials and uses them on web service call to login and go inside.
　　http://msdn.microsoft.com/en-us/library/ee557754.aspx