Here is a quick code that you need to include in your relying party’s global.asax file to setup a sliding window session for your federated / claims aware application.
void SessionAuthenticationModule_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e)
DateTime now = DateTime.UtcNow;
SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
e.SessionToken = sam.CreateSessionSecurityToken(e.SessionToken.ClaimsPrincipal, e.SessionToken.Context, now, now.AddMinutes(1), e.SessionToken.IsPersistent);
e.ReissueCookie = true;
The above code sets the sliding window to 1 minute.
In some cases, you may need to retrieve the context of the RP at the IdP end after passing through the FP.
For example, your IdP may want to know the name of the RP for which the token is being sought (although this may not a good design). In such cases it is possible to retrieve the context of the RP if you are using ADFS as the federation provider.
By default, the ADFS server encodes all the original context information about the relying party within a cookie when redirecting the user to the IdP. However, if you go the web.config file of ADFS and change the following context element to false, you will see now that the url when accessing the IdP contains a huge queryString (about half a page long).
<context hidden=“true“ />
What has happened is, ADFS instead of putting the original RP context into a cookie has stored it on the URL itself, but the original query sting is nested within another queryString, so if you are using a custom STS as your identity provider, you can use the following code to retrieve the original context.
string wctx = Request.QueryString[“wctx”];
string baseUrl = System.Web.HttpUtility.ParseQueryString(wctx).Get(“BaseUrl”);
Uri uri = new Uri(baseUrl.Replace(“\”, “?”));
string wtRealm = System.Web.HttpUtility.ParseQueryString(uri.Query).Get(“wtrealm”);