Skip to content

Overriding WS-Federation token lifetime in Thinktecture IdentityModel

February 17, 2013

As I described earlier, you can configure the default session token lifetime. One detail I didn’t mention was that with the technique I illustrated you can only make the session lifetime shorter than the original token lifetime, but not longer. The point of this post is to show how you can make the session token lifetime longer than the token issued from a STS.

Once the FAM (federated authentication module) receives a token and then issues a session security token, it raises a SessionSecurityTokenCreated event. It is at this point where you can configure aspects of the token. Unfortunately the expiration isn’t something you can set, but you can designate a different session security token essentially replacing the the one created by the FAM. Here’s how (assuming the event handler in global.asax):

void WSFederationAuthenticationModule_SessionSecurityTokenCreated(object sender, SessionSecurityTokenCreatedEventArgs e)
{
    var handler = (SessionSecurityTokenHandler)FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers[typeof(SessionSecurityToken)];
    var duration = handler.TokenLifetime;

    var token = e.SessionToken;
    e.SessionToken =
        new SessionSecurityToken(
            token.ClaimsPrincipal,
            token.Context,
            token.ValidFrom,
            token.ValidFrom.Add(duration))
        {
            IsPersistent = token.IsPersistent,
            IsReferenceMode = token.IsReferenceMode
        };
}

This code creates a new session security token (like described here) and it uses the duration as configured on the session security token handler (like described here). As with many of these behaviors, it’s not hard to configure in an application but it’s tedious. As such, this feature was added to the Thinktecture IdentityModel security library via the OverrideWSFedTokenLifetime API. It would typically be used in conjunction with setting the default session security token duration (like described here):

public override void Init()
{
    PassiveModuleConfiguration.OverrideWSFedTokenLifetime();
}

HTH

6 Comments leave one →
  1. February 18, 2013 12:19 pm

    Reblogged this on Peter's ruminations and commented:
    Does a security session token have a serialization (and does it conform to saml)?

    I ask as saml supports multiple name forms – a bit like a cert does. One cert name form is a directory name – a semantic that says a trusted directory node asserts the underlying dn. There is a dynamic birth (re)certificate for the dn that is. Just as a cert can wrap such a certified name (from a post cert-issuing-era verisign now managing trusted dns zones), an assertion can wrap a trusted name similarly. One form for trusted names (embedded in assertions) is an assertion! A
    assertion can have another assertion acting as the subjects name.

    Issuing security tokens lessens dependencies on the issuer as a session authority. The issuer can be limited to be limited to the role of an authentication authority (for names) only. Now if the session i issue in response to relying on the authn statement is also a serialized assertion, my sp can become an fp that cites the idp-issued name(s) in its own assertions name field

  2. RonyK permalink
    March 12, 2013 11:58 am

    Hi, We have a problem that when signing out from the relying party (clearing both relying party’s and Identity Server’s cookies) if we click the browser’s back button (twice) the form containing the token in the body is getting re posted to the relying party’s site, thus renewing the SAM session token and signing in again. This behavior persists as long as the life time of the token is still valid. Is there a recommended way how to resolve this issue?
    Thanks.

    • March 12, 2013 7:25 pm

      This would be the same issue with logging in with forms auth, no? So, not, I don’t have anything terribly clever to offer to prevent this.

      • RonyK permalink
        March 13, 2013 6:05 am

        I noticed that the relying party’s token lifetime could be configured (in the Identity server administration panel) to set a shorter lifetime for the token posted to the application, thus minimizing the time frame in which this issue can persist. Would that be a reasonable thing to do or could that cause other undesirable side effects?

        • March 13, 2013 6:19 am

          Ummm, well… I guess it’s whatever you want. Of course, a shorter token lifetime (without sliding sessions) means the user will need to re-authenticate more frequently. It’s up to your requirements, really.

  3. July 17, 2014 1:52 pm

    Does the PassiveModuleConfiguration.OverrideWSFedTokenLifetime(); line have to be in the Init() method rather than the Application_Start() method?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: