Understanding SharePoint 2010 Claims Authentication


This blog is intended to fill some gaps and provide a foundation to understand components in the claims model and how these components work together. Claims will provide a huge benefit which I will outline some of those benefits below. I suspect this will turn into a multi blog series so stay tuned for further blogs on this subject. The goal is providing a series of blogs starting from broad and getting more narrow in scope. As the scope is narrowed, a deeper technical progression will take place. SharePoint 2010 has a new approach to authentication\authorization. Instead of using the classic (Integrated) authentication method, it’s possible to authenticate and authorize users against external Identity Providers. No longer, are we limited to directory repository’s like Active Directory. In fact, it’s possible to create custom identity providers and SharePoint will trust and leverage that Identity Provider thus granting external user access to a SharePoint site/document etc…

Special thanks goes to Venky for the knowledge transfer  🙂

 

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:

clip_image002

 

clip_image004

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!

image

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

Thanks,

Russ Maxwell, MSFT


Comments (25)

  1. Pradeep says:

    Hi Russ,

    Can I consume Out of box STS of SharePoint 2010 from external System (a Claim Aware Web Application)?

  2. Russmax says:

    Pradeep, I believe your asking the following:

    Question: Can I use SharePoint 2010 STS as an identity provider?

    Answer:  I believe the answer is no because for sign-in the SharePoint STS depends on an identity provider if claims is specified.  Therefore, SharePoint 2010 STS by itself cannot fulfill this requests..

    make sense?

    Thanks,

    Russmax, MSFT

  3. Himani says:

    HI Russ,

    How can I use Windows Live ID as an STS for claims based authentication? Can you give me the detail steps? I have been unable to configure LIVE ID STS with claims SharePoint 2010 site.

    Thanks, Himani

  4. Pradeep says:

    Thanks RuSS

    I hava another and very important Q. I have a custom WCF service hosted in _vti_vin. Then I have a web application

    http://myserver:1234/  which is claim based web application.

    Ok, so now If I call my custom WCF Service like http://myserver:1234/_vti_bin/customservice.svc

    Question: Do I need claim to call this service?

  5. Rik Helsen says:

    You might be interested in a module Orbit One is sharing on it's website:

    http://www.orbitone.com/…/SharePoint2010automaticsignin.aspx

    You get automatic selection of the right authentication provider based on IP address mapping.

    When using Windows Authentication for an intranet environment this brings back transparent authentication based on the Windows credentials.

    Transparent sign-in with Windows Authentication, when using multiple authentication providers. No more '

    * Support for IPv6

    * Map IP addresses to an authentication provider

    * Wildcard mapping

    * Configuration through Powershell

    The solution consists of two parts:

    *  A custom PowerShell snap-in that is used to manage the mappings between IP addresses and authentication providers. The mapping is stored in the Hierarchical Object Store, on the level of the Web Application.

    * A custom sign-in page. When the custom sign-in page is loaded it will first check the IP address of the user. Then it will check if the address is mapped to an authentication provider. If it is mapped, the user will be redirected to the sign-in page of that provider. In other words, if the mapping is found the “Select the credentials you want to use to logon to the SharePoint site” step of the sign in process is automated.

  6. Erik McCarty ewmccarty@gmail.com says:

    I've set up a SharePoint list with a workflow that updates an External Content Type, but the workflow is failing with an access denied error when it goes to execute the 'Read List' of the ECT. The error even states that both of my domain accounts have permission, but the account SharePoint identifies as trying to perform the workflow is denied and appears slightly different though all of the account references are the same Active Directory username and password.

    Does error log entry this yield any clues at to what is the source of the problem?

    09/22/2010 15:42:25.27      w3wp.exe (0x1F8C)                         0x1CF4          Business Connectivity Services            Business Data                       g0jq     High

    Access Denied for User '0#.w|mybusinessdomainewmccarty', which may be an impersonation by 'MYBUSINESSDOMAINSP2010SA'. Securable MethodInstance with Name 'Read List' has ACL that contains:

    User 'i:0#.w|mybusinessdomainewmccarty' with Display Name 'Erik W. McCarty' with Rights 'Execute, Edit, SetPermissions, SelectableInClients'    

    User 'i:0#.w|mybusinessdomainemccarty' with Display Name 'Erik McCarty' with Rights 'Execute, Edit, SetPermissions, SelectableInClients'        

    05275adc-2ec6-4949-9528-c94908830f6c

  7. Matt says:

    Can clams be used to authenticate users from two entirely different AD forests? without ADFS or a trust?

  8. MichaelPacifico says:

    Russ,

    Do you have any info about integrating SharePoint with Oracle Access Manager?  Wondering how the new claims auth works with this in 2010.  Everything I see is related to 2007 and FBA.  Thanks!

  9. Nino says:

    I had enabled claims Authentication and configured Forms Based Authentication (FBA) with membership provider in SharePoint 2010.

    The logged-on user is kicked out when the page is redirected from https to http.

    FedAuth cookie is not valid after redirecting from https to http.

    Does anyone have any suggestions?

  10. Harry says:

    Hi  Himani,

    Check this out, it about how SharePoint 2010 connect to App Fabric Access Control v2.

    blogs.msdn.com/…/understanding-sharepoint-2010-claims-authentication.aspx

  11. Harry says:

    Hi  Himani,

    Check this out, it's about how SharePoint 2010 connect to App Fabric Access Control v2.

    blogs.msdn.com/…/understanding-sharepoint-2010-claims-authentication.aspx

  12. Mark Wilson says:

    So basically FBA now goes through the SP2010 claims system? The only issue is that the SPClaimsAuthMembershipProvider doesn't implement GetUser(string,bool) which makes it quite difficult to use a lot of FBA solutions like password reset etc. The MSDN documentation claims it is implemented but any attempt to use it results in a NotImplementedException.

  13. Filipe says:

    Hi Russ. One short question: can i do claims augmentation with a custom claims provider on integrated NTLM Windows Authentication? Thanks.

  14. Steve says:

    Very well written Russ.  You paint a clear picture!

  15. vilas6_it says:

    On a Farm for all web applications both Classic authentication and Claims based (SAML token) authentication has been setup.  Anonymous access is enabled in IIS, But turned off at SharePoint web application level.

    IIS logs have been configured. I see that all windows (Classic) authenticated users are logged in IIS logs cs-username field. But, SAML users are not getting logged in IIS logs i.e. “cs-username” field is empty.

    Any Idea on why SAML users are not getting logged in IIS logs cs-username field, but windows user are getting logged?

    Is SAML authentication ticket stored in a cookie after authentication?

    How to make SAML Users get logged in IIS logs cs-username filed?

  16. Rajesh CR says:

    Hi Russ,

    I have two web application(say web1,web2). Both are NTLM Claim Authentication. I have an image file in web2 ( http://web1/images/1.jpg). I tried to insert that into a wiki page. While accessing WEB1 I provide my NT credentials and application is asking second prompt for authenticating  web2.

    How do I solve this issue with single authentication? I require to repeat this for ADFS also. Could you help me?

  17. PRADP says:

    hi Russ,

    We have created a sharepoint site and used both NTLM and (CBA)Claim Based Authentication(ADFS in this case as Identity Provider).We are able to successfuully authenticate using the CBA and sign in into the site.

    ISSUE:

    Everytime we try to click on a link n the site to navigate to a different page, we get the pop up that shows to choose the multiple authenticaton types(windows authentication and the claim based authentication we have configured ( ADFS in this case).and, once we choose the claim based auth, it takes us directly to the page.

    Is this issue because  we have configured multiple authenticaton type(NTLM and CBA (ADFS as out truseted identity provider).

    Any resolution for this?

    Regards

    PRADP

  18. Le Huy Luyen SharePoint Team Vietnam says:

    Thanks for your shared info.

  19. Lucky says:

    Well written. Helped a lot in understanding the basics

  20. Rizwan Ansari says:

    We are planning to migrate to claims based authentication in SharePoint 2010. We will be creating number of ASP .NET web application which will be claims aware and will be authenticating off the ADFS. The web application will accept windows logon or can be forms based.

    Now we want to implement Single Sign On, where a user logged in to SharePoint does not need to login again to custom ASP .NET application and vice versa.

    I have seen many article, but I am not getting proper lead on the correct way to go with.

    Please help.

  21. SP2010 says:

    Before we had a Claims-FBAuthentication and we want to change to Claims-Windows authentication only.Pls let us know the steps to be followed inorder to login from windows. Now, when I open the website, it asks me to login with the windows auth dialog which never signs in.

  22. Ambarish Singh says:

    Thanks a ton Russ for such a clear documentation on claims authentication. Very impressive.

  23. Sudarshan Bodke says:

    Hey nice article , loved it . Cleared quite some doubts

  24. Harika says:

    Hi,

    How can we access sharepoint web services present in this environment? How should the handshake happen between client application and the sharepoint server?

  25. Songita says:

    Russ,

    Wonderful documentation. Helped me a lot to understand the concepts.