Exercise 4: Invoking a WCF Service on the Backend via Delegated Access
One common practice in ASP.NET development is user impersonation. A website may need to access resources with the privileges of the incoming user, hence there are mechanisms in place that allow the application itself to operate under the current user’s identity. One possible issue with this approach is that it offers a large attack surface: a successful hack of the application will lead to acquiring the user’s privileges no matter which part of the application was subverted.
Windows Identity Foundation provides the means for mitigating this, by allowing an ASP.NET application to choose when to act as the current website user in delegated invocations and when to use its own application identity regardless of who the current user is (hence behaving as a trusted subsystem).
From the architectural point of view, Windows Identity Foundation achieves this by leveraging the ActAs mechanisms defined in the WS-Trust protocol. The ASP.NET application’s code behind requires a token to an STS using its own application credentials, however it also attaches to the request the token that the current user sent in order to authenticate with the website: the STS processes the request and issue a delegated token, which in turn the ASP.NET application uses for invoking a web service acting as the website user.
From the practical point of view, this means that the ASP.NET developer needs to follow few extra steps before calling the backend service he needs. In the following exercise we will demonstrate exactly that, showing how to augment the solution we built in the former exercises with a delegated call to a backend service.
The Delegated Access scenario implemented in exercise 4
Task 1 - Inspecting the Beginning Solution
Task 2 - Configuring the Client in the Relying Party to Access the RevenuesService
Task 3 - Calling the Service
Exercise 4: Verification
In order to verify that you have correctly performed all steps in exercise four, proceed as follows: