Peace be upon you,
For having understanding of SP 2010 claims authentication, please read the below, it is really clear and summarized:
Following the paradigm shift from SSPs to Service Applications, authentication has been “offloaded” to the “Security Token Service Application.” The “STS” (as it’s known) is one of those service applications that has no configurable properties. (When you select it in Central Admin, the “Properties” and other Ribbon options are disabled.) This is, as far as I’m concerned, both good and bad: good because there’s nothing extra there to break; bad because there’s nowhere to go to fix it when it indeed is broken. Behind these ominous scenes, the STS is just a WCF service, hanging out in “14\WebServices\SecurityToken.” They way this works is that SharePoint routes all authentication through this service. Whenever anyone logs into anything, STS is the mechanism giving users the nod. Now, the web applications are still operating as normal ASP.NET sites; authentication, authorization, forms, etc. (in terms of configuration) don’t change. It’s just that instead of code running the web app to do the work, a service call is made instead. So architecturally, this is really the only big change. In 2007, each web app (Central Admin included) did its own thing for auth. 2010 has now integrated this into its service application layer, with all web apps plug into. However there is one caveat that will lead us into the second part of this post which covers implementation. Even though the STS handles authentication, web apps are still on their own to implement all other user-centric functionality. The best example is the PeoplePicker. Despite the PeoplePicker depending on the very same mechanics as the STS’ authentication and authorization do, it’s not actually doing authentication or authorization; it’s simply querying into these interfaces against our user store (weather it’s AD, SQL, etc.). What does this mean to us? Basically, when implementing custom authentication or authorization, the STS is what needs to be configured to talk to the ASP.NET MembershipProvider. However, any web app that needs to interact with these users, be it searching within a PeoplePicker, adding users to a group, or granting people Site Collection Administrator permissions in Central Admin, needs to be configured to use the authentication provider as well. Just not for authentication. So in SharePoint 2010 Claims-based Authentication, there are now three places you need to go to configure a custom authentication provider (verses just two in 2007): the web application itself (to allow permission and security functionality to work), Central Admin (to implement the provisioning of Site Collection Administrators and other more global user management tasks), and STS (which, again, is doing the actual authentication). Before we move on to the implementation, I want to briefly discuss some semantics. As it stands, offloading authentication across the farm to the STS does not constitute “claims” authentication all the way. In claims (with a lower-case “C”) auth, you provide your credentials to a third party “issuer” who authenticates you and gives you (or your session) a token. It is this token that you give to the actual site or application. So STS is the first “half” of this paradigm. What about the token? That is abstracted to us, and SharePoint wires up its own “claims” provider that does this work for us. We’re using claims auth without having to worry about anything beyond forms auth!
1. Forms authentication is configured for the web app, so it knows to provide a login page to you.
2. The login page passes your credentials to STS.
3. STS uses our custom provider to authenticate you and issues back a token.
4. This token is sent to the web app, which uses the SPClaimsAuthMembershipProvider and SPClaimsAuthRoleProvider to process the token and use it for final authentication and authorization respectively.
5. The web app then uses the custom provider directly to power user-centric functionality, such as the PeoplePicker.