Analysis

1. Client browser sends a HTTP GET request to a claims aware ASP.NET web application at https://localhost/ClaimsAwareASPX/default.aspx
2. WIF intercepts that request and detects that the request does not have the proper security token so WIF redirects the user to the configured issuer, CustomSTS, at https://localhost/CustomSTS/default.aspx
3. The CustomSTS federates with Windows Azure ACS so the user is redirected to Windows Azure
4. Windows Azure has a relying party trust for the CustomSTS, with Windows Live ID as the identity provider so the user is redirected to Windows Live to login for authentication
5. The user has been authenticated with Live ID and now has security token with a set of claims added by Windows Live ID. For step five here it’s actually not a direct call from Live ID to Azure, that implementation actually goes back to the client browser and the immediately redirected back to Azure
6. Azure accepted the security token from LiveID, performs its authorization, adds or manipulates claims if configured and then redirects the browser back to the CustomSTS passive endpoint.
7. The browser presented a valid security token to our CustomSTS passive endpoint, so the CustomSTS performs any authorization and also has an opportunity to add more or manipulate the set of claims and then redirects the client browser back to the ASPX relying party application but this time with an issued and trusted security token
8. In this step the code inside default.aspx of our ASPX relying party begins to run. Inside the Page_Load event we attempt to call to the backend claims aware WCF service. The WIF and WCF configurations require the ASPX client to make a WS-Trust call to the active endpoint of our CustomSTS to get a required security token before talking with the backend WCF service. The ASPX page passes in the bootstrap token in that call to the CustomSTS active endpoint
9. The CustomSTS Active endpoint (ActAsIssuer.svc) authenticates the caller using ws2007httpbinding, does any desired authorization, and then issues a security token with a set of claims for the bootstrap token user. Our sample adds two more claims to this list and returns the security token back to the ASPX client
10. The ASPX client now has the required security token to call our backend WCF Service. The call is made.
11. The WCF service method executes, it simply enumerates the set of incoming claims that are populated by WIF using the incoming security token on the IClaimsIdentity object and returns the set of claims as a generic list
12. The ASPX relying party app now gets the set of claims returned from our WCF service method and then dumps out the set of claims it received from the CustomSTS passive endpoint and then also dumps out the set of claims it received from the WCF service method all and displays it on the page to the browser client.