How to define a desired life time in the security token request

Question

Hi,
 
I'm writing a custom STS, where I have been able to set a token lifetime by overriding 
    SecurityTokenService.GetTokenLifeTime()
and all is fine.

However, I cannot find any information on how to on the service consumer side (i.e. the token requester) set a desired lifetime.

So the scenario I want is the following:

- Client sets a desired token lifetime that is used in the request (for a SAML 2.0 token)
- STS reads the request, extracts the info of the desired lifetime, and decides whether to comply or give the token a different lifetime
- Client receives the token (and fails in case the lifetime is shorter than the desired one)

Is there a way to implement this using geneva?

Best regards,
Patrik

Answer 1

Hi,

the default behavior is this:

the base class implementation of GetTokenLifetime checks whether a specific life time is requested. If this is not the case, the value of DefaultTokenLifetime on the SecurityTokenServiceConfiguration is used.

If there is a specific lifetime requested, there is an additional check if this lifetime exceeds the MaximumTokenLifetime on SecurityTokenServiceConfiguration. If this is not the case, the token gets this specific lifetime. Otherwise an exception is thrown.

If you like this behavior, i would recommend setting the appropriate values on the config class and not overriding GetTokenLifetime.

The client requests a specific lifetime by adding the appropriate element to the RST (exact name escapes me - the WS-Trust spec knows more). You can do this directly when using WSTrustClient. IIRC this is not exposed directly by the standard binding - but you can definitely set this via an additional token request parameter on the federation binding.

HTH

---

Dominick Baier - http://www.leastprivilege.com

Answer 2

Either I am missing something, or this doesn't appear to be enforced. I set my STS config to 15 seconds default token lifetime, but the RP still allows the token after that period expires. I haven't dug deeper yet but it would be good to know if there is another step required.

---

Michele Leroux Bustamante | Chief Architect, IDesign | www.thatindigogirl.com

Answer 3

Have you looked at the raw token? The NotOnOrAfter field? Is this correct?

What do you mean with "RP still allows the token" - are you talking about the bootstrap token? or the session token afterwards?

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 4

Actually it does work!!! I had set the token expiry properly but was looking at the wrong binding with ReceiveTimeout, the session wasn't expiring for my test.

If you're interested, I published some samples at http://claimsbasedwpf.codeplex.com that include a proxy wrapper that recreates the channel on session timeout and faulted channels, used a shared token across multiple RP services (same RP of course), reuses the token if channels expire and are recreated, gets a new token if the token expires, and gets a collection of claims from the RP to use for claims-based UI filtering at the client, updates those claims when a new token is requested. Feedback welcome.

---

Michele Leroux Bustamante | Chief Architect, IDesign | www.thatindigogirl.com

Answer 5

 Hi, I faced the same kind of problem as you Michele. I then adjusted the ReceiveTimeout on my RP's federation binding so the session timed out. Then it worked as expected. But how come? What are the relationships between the SAML:s expiration point, ValidTo, and ReceiveTimeout. Is it that if a session has been established, that to ValidTo value is ignored? Maybe I am missing something obvious here.

/Stefan

Answer 6

Dealing with lifetime is tricky, some things to consider:

1. Clock Skew: WIF and WCF have a default clock skew of 5 minutes, which is a tolerance added to all time-related checks to allow for two parties in a transaction having clocks that are not in sync. A token that indicates expiry at 3:00pm, for example, would be treated as if it had an expiration date between 2:55pm and 3:05pm due to clock skew.

2. Session mechanics: If some sort of a session is enabled, be it a WCF SecureConversation session or an ASP.Net federated authentication cookie, effectively the issued token is exchanged for a session token or a cookie. Opinions differ on whether the issued token lifetime should carry over to the session lifetime, and I don't know off the top of my head what WIF does in this case, but it's likely that the lifetime of the session is distinct from the lifetime of the issued token.

---

Shiung Yong - Windows Identity Foundation