It is very typical of the frontend web applications to participate in an act-as scenario in web-based SSO. They are required to impersonate the user in an incoming service request and authenticate against a WCF service deployed in the same or a different trust realm. The following diagram illustrates this scenario:
In this recipe, we will continue from where we left off in the previous recipe and showcase how a federation server configured using AD FS 2.0 can be used to delegate the identity to a service. In this particular example, we will create a claims-enabled WCF service that will be used by the ASP.NET Web Application created in the previous recipe to showcase the identity delegation. For simplicity, we will consider both the frontend application and the backend service to be under the same domain (trust realm).
To implement the identity delegation, perform the following steps:
- Create a Claims-aware WCF Service from the Visual Studio 2010 C# Web Site templates:
- Host the service in Local Internet Information Server as ClaimsEnabledService (
https://adfsweb.domain.com/ClaimsEnabledService), as shown in the following screenshot:
- Configure the trust relationship between the WCF service and the federation server by performing the steps outlined in the previous recipe. Make sure that for the WCF service, you select the Encrypt Token option in the Federation Utility Wizard. Once the Federation Utility Wizard completes, modify the
Web.configfile to update thews2007FederationHttpBindingelement with the following changes:
- In the AD FS 2.0 management console, click on Edit Claim Rules… to launch the Edit Claim Rules for ClaimsEnabledService dialog box and go to the Delegation Authorization Rules tab, as shown in the following screenshot:
- Click on Add Rule… to launch the Add Delegation Authorization Claim Rule Wizard and select Pass Through or Filter an Incoming Claim under the Claim rule template drop-down menu. Click on Next, as shown in the following screenshot:
- In the Configure Claim Rule step, specify the Claim rule name as Windows Account Delegation and select Windows account name from the Incoming claim type drop-down menu. Click on Finish to complete running the wizard:
After this step, you are now ready to consume
ClaimsEnabledServicein theClaimsEnabledAppweb application.
Most of the steps in this recipe are self-explanatory and have been already described in the previous recipe. The most important step to note here is that without configuring the claim rules under the Delegation Authorization Rules tab, no user will be permitted to act as a delegate for other users to the relying party. A couple of changes are needed in the Web.config file while consuming the service in the ClaimsEnabledApp web application (by adding a service reference). You have to make sure of the following two things:
- You need to specify the
<identity>element under the<issuer>tag, as shown in the following code snippet:<identity> <servicePrincipalName value="adfsweb.domain.com"/> </identity>
- You need to set the
saveBootstrapTokensattribute totrueunder the<microsoft.identityModel> <service>element. This instructs the WIF runtime to store the security token in session.
You can now use the createChannelActingAs method in the web application to make a delegated call to the WCF service. This is described in Chapter 2, Overview of Claims-based Identity.
You can learn more about the identity delegation in the MSDN article — Identity Delegation with AD FS 2.0 Step-by-Step Guide at http://technet.microsoft.com/en-us/library/adfs2-identity-delegation-step-by-step-guide(WS.10).aspx with an elaborate scenario example.