Refreshing Claims in a WIF Claims-Aware Application
With Windows Identity Foundation (WIF), it’s fairly simple and well-documented on how to consume claims in your claims-aware web application. What isn’t entirely clear is how to reload these claims when updates are made to the user’s information. How do we refresh the claims, which are stored in an encrypted SAML token cookie?
Let’s look at a fairly simple WIF application that allows users to update their profile — their email address, name, title, and possibly other user information. In a typical scenario, there would be a call to make a database update and then a subsequent query to retrieve the new data. However since our claims are controlled by the Security Token Service (STS), we need to somehow force the claims to be refreshed by the central STS.
This is done by making a call to the WSFederationAuthenticationModule to “sign out” the user:
var module = Context.ApplicationInstance.Modules["WSFederationAuthenticationModule"] as WSFederationAuthenticationModule; module.SignOut(true);
So what does this actually do? Well, let’s look at the process from the beginning:
- When a user authenticates successfully, a POST is sent back to the relying party endpoint. This request contains our SAML token that is then stored within a browser cookie. In fact, several cookies are written as can be seen in the list below:
- When the updates are made, we need to get a reference to the WSFederationAuthenticationModule, which sits in the ASP.NET pipeline and monitors the presence of the authentication cookies.
- With our module instance, we can then call SignOut, which simply deletes the session token cookie (FedAuth).
- The next request for a secured page within our application will require a hop over to the STS. Since the user is still authenticated based on the authentication cookies, the STS will reissue fresh claims and a new session token!
This process is transparent to the user since the hop is fairly quick, and it allows us to easily reload the user profile information.