Identity Delegation
Applies to: SharePoint Foundation 2010
Identity Delegation
This scenario describes an application that needs to access back-end resources that require the identity delegation chain to perform access control checks. A simple identity delegation chain usually consists of the information on the initial caller and the identity of the immediate caller.With the Kerberos delegation model on the Windows platform today, the back-end resources have access only to the identity of the immediate caller and not to that of the initial caller. This model is commonly referred to as the trusted subsystem model. Windows Identity Foundation (WIF) maintains the identity of the initial caller and the immediate caller in the delegation chain by using the Delegate() property.
The following diagram shows a typical identity delegation scenario in which a Fabrikam employee accesses resources exposed in a Contoso.com application.
.gif)
The fictional users participating in this scenario are:
Frank: A Fabrikam employee who wants to access Contoso resources.
Daniel: A Contoso application developer who implements the necessary changes in the application.
Adam: The Contoso IT administrator.
The components involved in this scenario are:
web1: A Web application with links to back-end resources that require the delegated identity of the initial caller. This application is built with ASP.NET.
A Web service that accesses a computer running Microsoft SQL Server, which requires the delegated identity of the initial caller, along with that of the immediate caller. This service is built with Windows Communication Foundation (WCF).
sts1: A security token service (STS) that is in the role of federation provider, and emits claims that are expected by the application (web1). It has established trust with Fabrikam.com and also with the application.
sts2: An STS that is in the role of identity provider for Fabrikam.com and that provides an endpoint that the Fabrikam employee uses to authenticate. It has established trust with Contoso.com so that Fabrikam employees are allowed to access resources on Contoso.com.
Note that the term "ActAs token", which is used often in this scenario, refers to a token that is issued by an STS and that contains the user’s identity. The Delegate() property contains the STS's identity.
As shown in the previous diagram, the flow in this scenario is:
The Contoso application is configured to obtain an ActAs token that contains both the Fabrikam employee's identity and the immediate caller's identity in the Delegate() property. Daniel implements these changes to the application.
The Contoso application is configured to pass the ActAs token to the back-end service. Daniel implements these changes to the application.
The Contoso Web service is configured to validate the ActAs token by calling sts1. Adam enables sts1 to process delegation requests.
Fabrikam user Frank accesses the Contoso application and is given access to the back-end resources.