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:
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.
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 token3. Client attempts to authenticate to trusted Identity Provider4. 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 augmentation8. 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 credentials2. SharePoint STS calls membership provider to authenticate3. SharePoint STS calls role provider to get all the roles for the user4. Post successful authentication, a SAML token is generated by the SharePoint STS and passed back to the user5. 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
My beta rotation ended this May and I’m back in my role of supporting Premier Customer’s with various SharePoint issues. Please no v2 issues :) This was my first experience joining any sort of beta program at MSFT. I really feel fortunate being involved in this particular beta because we have made so many improvements in this build of SharePoint. I’ll continue to blog on various SharePoint topics but will probably introduce more troubleshooting type blogs since our documentation on SharePoint 2010 is great.
Special thanks to Sheyi, Dan W., Doron, Luca, Jim, Radu and countless others I’ve interacted with over the past year…
I thought I would post some links to some SharePoint 2010 and SharePoint 2007 content that I’ve found along the way..
SharePoint 2010 Developer Training
Microsoft SharePoint Product Group Blog
Microsoft Enterprise Search Blog
SharePoint FaceBook
SharePoint Updates on FaceBook
TechNet
TechNet Library
Microsoft SharePoint Designer Team Blog
Detailed list of SharePoint 2007 Cumulative Updates
Detailed list of SharePoint 2010 Cumulative Updates
Stay tuned… More blog content is coming soon :)
-Russ Maxwell, MSFT
This is a short blog which briefly discusses Shared Service Architecture in a multi farm environment. I will discuss some core components and describe how these components work together. I will not go into exact setup steps due to the fact TechNet has a great run through here:
Exchanging Certs: http://technet.microsoft.com/en-us/library/ee704552(office.14).aspx
Publishing a Service Application: http://technet.microsoft.com/en-us/library/ee704545(office.14).aspx
Connecting to a Published Service Application: http://technet.microsoft.com/en-us/library/ee704558(office.14).aspx
Special shout-out goes to Ram and Sheyi for some great contributions to this blog. I recommend reviewing Shared Service Architecture Part 1 blog to build a foundation before continuing further.
Basics
SharePoint 2010 Shared Service architecture has been revamped to provide great flexibility in a single farm. This flexibility in a single farm has been extended to include multiple farms. For Example, Shared Services can exist in a farm I’ll call “Services Farm”. All content like SharePoint sites and My-Sites reside in a farm called “Consumer Farm”. A services farm consists of multiple shared services that can be published and made available to remote farms. The Consumer Farm can connect to a published service application from the services farm and consume from it.
For Example:
Services Farm: Published Search Service Application and give Admin access via permissions button for the specified service application.
Consumer Farm: Consumes Search Service Application from Services Farm
Action from Consumer Farm: User accessing a site performs a search
Results from Services Farm: Search results are pulled from Services Farm.
Initial Deployment is a four step process.
Note: The STS cert is provided to the Publishing farm from the Consumer farm
2. On the services farm, publish shared service applications making them available to other farms
3. Set Permissions on who can access the published shared service applications
4. The consumer farm will use Connect button to discover the services in a destination farm and to create a Proxy to a Shared service in a remote farm.
Note: A successful attempt at step 4 creates a service application proxy and places in a proxy group within the Consumer farm. Only web applications mapped to the same proxy group will consume from this published service application.
Topology Discovery Service Application
This is known as the Application Discover and Load Balancer Service Application, “I’ll refer to as the topology service”. Within IIS, it’s listed as Topology and runs using WCF web service.
Central Administrator:
IIS:
Without a Topology Discovery Service Application, consuming services across farms is not possible. Why it’s not possible will be answered when the entire blog has been reviewed.
Functions of Topology Service on publishing farm
In a services “publishing” farm, the topology service provides a list of published shared service applications that are available for consumption. It also keeps track of which Published Shared Service application instances are online\offline so that it consistently maintains a fresh list of URI’s. It maintains a cache of these URI’s to avoid multiple round trips to the configuration database.
Functions of Topology Service on consuming farm
The topology service functions in a consuming farm take effect only after a connection is established. That is, a service application proxy is created on a consumer farm that connects to service application in publishing farm. In a consumer farm, the topology service connects to the Publishing farms (remote) topology service to retrieve a list of added/removed URI’s. A timer job controls when this takes place called the Application address refresh timer job. The default is every 15 minutes. When it runs, it calls the Publishing farm’s Topology Web Service to retrieve the updated service end-point URI list. If there is any change, it will update the associated service application proxy.
Load Balancer
The load balancer component provides two functions in a content farm:
1. It ensures request from service application proxies are evenly distributed to remote published shared service instances.
2. Maintains a list of fresh URI’s
On a consumer farm, when a service application proxy is first provisioned that is consuming service in a remote publishing farm, the service application proxy directly connects to the publishing farms remote topology service to get the list of available URI’s (See the troubleshooting section for more details). It stores these URI’s in a load balancer cache. Therefore, each service application proxy in a consuming farm contains a unique load balancer component. After the initial provision, the load balancer component will not attempt to connect to the remote topology service again to receive URI updates. It will only receive updates from the local topology service via the Application address refresh timer job.
Question: What if a load balancer discovers service connection endpoints are down?
Answer: It maintains freshness in that when it discovers service endpoints are no longer available it marks them as down for a period of time and will not use it until that time period has expired. For further service calls, the load balancer tries to get the next available URI from its cache. When the time period is over, it will bring the downed link back online.
Troubleshooting Topology Service (basics)
This section will uncover what takes place behind the scenes “what the trace logs look like” on various aspects of multi farm communication. I’ll cover each action in its own section. The data provided will display a glimpse of healthy activity and can be used as a reference based on the type of action taken.
Connecting to Topology Service to consume Search Service Application
In this example, SharePoint administrator in consumer farm is connecting to topology service in publishing farm and selecting a Search Service Application to consume from it:
03/08/2010 09:03:03.08 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (POST:http://consumerfarm:4444/_admin/ServiceApplicationConnect.aspx?IsDlg=1) bcb6e7a2-4749-4c2d-99d0-49ad45544e1d
03/08/2010 09:03:03.11 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology 84cy Verbose Retrieving shared service application information for url: 'https://servicesfarm:32844/Topology/topology.svc' bcb6e7a2-4749-4c2d-99d0-49ad45544e1d
03/08/2010 09:03:03.11 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology 84d0 Verbose The specified url is not topology service load balanced. Assuming the uri is hardware load balanced for the topology service 'https://servicesfarm:32844/Topology/topology.svc' bcb6e7a2-4749-4c2d-99d0-49ad45544e1d
03/08/2010 09:03:03.30 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: 'https://servicesfarm:32844/Topology/topology.svc' Channel: 'Microsoft.SharePoint.ITopologyWebServiceApplication' Action: 'http://tempuri.org/ITopologyWebServiceApplication/EnumerateSharedServiceApplications' MessageId: 'urn:uuid:ace71aeb-f378-41d2-8593-e43af416c98b' bcb6e7a2-4749-4c2d-99d0-49ad45544e1d
03/08/2010 09:03:03.44 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (GET:http://consumerfarm:4444/_admin/SelectApplication.aspx?proxyId=&typeId=&IsDlg=1) 1aeaeebc-e766-41af-89c7-9d4ece0f24b0
03/08/2010 09:03:03.44 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology 84d3 Verbose The specified url is a topology service url. Not filtering retrieved results bcb6e7a2-4749-4c2d-99d0-49ad45544e1d
03/08/2010 09:03:03.45 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation General 6t8b Verbose Looking up context site http://consumerfarm:4444/_admin/SelectApplication.aspx?proxyId=&typeId=&IsDlg=1 in the farm SharePoint_Config2 140e4dd4-fa79-47f9-b0c5-9e638dad9258
03/08/2010 09:03:03.45 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation General 6t8h Verbose Found typical site / (cd40b0f0-3b69-484a-94b6-30bdb2def735) in web application SPAdministrationWebApplication. 140e4dd4-fa79-47f9-b0c5-9e638dad9258
03/08/2010 09:03:03.50 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology 84d4 Verbose Getting supporting proxy types for application 'Search Service Application 1' using proxyId '00000000-0000-0000-0000-000000000000' and typeId '00000000-0000-0000-0000-000000000000' 140e4dd4-fa79-47f9-b0c5-9e638dad9258
03/08/2010 09:03:03.50 w3wp.exe (0x0A00) 0x07AC SharePoint Foundation Topology 84d5 Verbose Found supporting proxy '' for application 'Search Service Application 1' 140e4dd4-fa79-47f9-b0c5-9e638dad9258
03/08/2010 09:03:11.67 OWSTIMER.EXE (0x0FEC) 0x11AC SharePoint Server Search Administration dk3p Verbose SearchService.Provision: Begin. 5483fb53-a1f1-4cec-b08f-803a4b15d422
03/08/2010 09:03:11.67 OWSTIMER.EXE (0x0FEC) 0x11AC SharePoint Server Search Administration dk3s Verbose SearchService.Provision: End. 5483fb53-a1f1-4cec-b08f-803a4b15d422
Communication to web services
In this example, user Dan is attempting to edit his profile and populate some properties. He is logged into Consumer farm which is consuming Profile Service application in services farm. To find which URI is being used by the User Profile Service Application Proxy, filter the ULS log to (category = Topology and Message contains = WcfSendRequest).
03/08/2010 06:05:01.23 OWSTIMER.EXE (0x0FEC) 0x1134 SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: 'http://servicesfarm:32843/fe60ff7b10af4828a2b76ca61ee38da6/ProfilePropertyService.svc' Channel: 'Microsoft.Office.Server.UserProfiles.IProfilePropertyService' Action: 'http://Microsoft.Office.Server.UserProfiles/GetProfileProperties' MessageId: 'urn:uuid:6868c5bd-a277-4593-ba77-4821840c713f'
03/08/2010 06:30:07.16 OWSTIMER.EXE (0x0FEC) 0x0A60 SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: 'http://servicesfarm:32843/fe60ff7b10af4828a2b76ca61ee38da6/ProfileDBCacheService.svc' Channel: 'Microsoft.Office.Server.UserProfiles.IProfileDBCacheService' Action: 'http://Microsoft.Office.Server.UserProfiles/GetUserData' MessageId: 'urn:uuid:cd65949f-cccd-425c-8c43-de26e4db9c79' ffbe7cb1-0db1-4966-8196-f533c54eaccf
This is ideal for troubleshooting in that you can see the URI specified. Also, this is a valid first step to validate were successfully reaching the service application instance. This could also be coupled with Netmon and\or Fiddler to get a complete picture.
Application address refresh timer job
Again, the Application Address refresh timer job executes on consumer farm and connects to remote Services farm’s topology service. It fetches changes (Added\Removed URI’s). In the following example, the consumer topology component is fetching the latest changes for one published service application. In this example, no updated changes are discovered.
03/08/2010 14:32:16.48 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Logging Correlation Data xmnv Medium Name=Timer Job job-spconnectedserviceapplication-addressesrefresh 5af1cadb-02f8-4522-a6ab-a5451a738e26
03/08/2010 14:32:15.47 OWSTIMER.EXE (0x0FEC) 0x0AD4 SharePoint Foundation Timer 5utp Verbose Scheduled timer job Application Addresses Refresh Job, id {879484E3-BFEB-436E-9FC1-B26C810BCA29} at 08 Mar 2010 14:32:16 -0800 (now is 08 Mar 2010 14:32:15 -0800)
03/08/2010 14:32:16.48 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: 'https://servicesfarm:32844/Topology/topology.svc' Channel: 'Microsoft.SharePoint.ITopologyWebServiceApplication' Action: 'http://tempuri.org/ITopologyWebServiceApplication/GetEndPoints' MessageId: 'urn:uuid:282a3a03-4a87-4d81-9fb0-be529953cdf6' 5af1cadb-02f8-4522-a6ab-a5451a738e26
03/08/2010 14:32:16.48 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Monitoring nasq Verbose Entering monitored scope (ExecuteWcfOperation:http://tempuri.org/ITopologyWebServiceApplication/GetEndPoints) 5af1cadb-02f8-4522-a6ab-a5451a738e26
03/08/2010 14:32:16.53 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Topology 3ls4 Verbose Application addresses for connected application: 46ad8378-690c-4568-b8d8-2485b1b89c1b are up-to-date 5af1cadb-02f8-4522-a6ab-a5451a738e26
03/08/2010 14:32:16.53 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Monitoring b4ly Verbose Leaving Monitored Scope (ExecuteWcfOperation:http://tempuri.org/ITopologyWebServiceApplication/GetEndPoints). Execution Time=49.8323110898173 5af1cadb-02f8-4522-a6ab-a5451a738e26
03/08/2010 14:32:17.31 OWSTIMER.EXE (0x0FEC) 0x1200 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (Timer Job job-spconnectedserviceapplication-addressesrefresh). Execution Time=830.343800678578 5af1cadb-02f8-4522-a6ab-a5451a738e26