Sliding Sessions with ACS

Question

Is it the case that the Token Lifetime value (http://msdn.microsoft.com/en-us/library/gg185906.aspx#BKMK_5) does not 'slide' by default? 

That is, if you've set the lifetime to 600 seconds, users on your web site have to re-authenticate every 600 seconds.  A user actively making requests and submitting GETs and POSTs has to re-authenticate 600 seconds after their last Authentication even if their last POST was 30 seconds ago? 

The discussion in Programming Windows Identity Foundation (page 122) implies this, but just wanted to verify it's still the case for Azure App Fabric ACS.

Thanks in advance.

 

---

Regards, Howard Hoffman

Answer 1

This is not determined by ACS directly. The token ACS issues will expire at a given time, based on the configured lifetime and the time the token is issued. Regardless of what is done with that token, it will expire at that time and it is up to the relying party application to reject the expired token, meaning that the user will need a new one.

Answer 2

So if I expand the answer to also include WIF, I understand you to mean "no, nothing you have out of the box, including WIF, will modify the Token Expiration once pushed out by Azure ACS".  Thanks for the good information.

I will attempt to incorporate something like Vittorio's published example to use the WIF SessionAuthenticationModule to play with the expiration date.

Am I going down a rat hole here?  Are there other examples that I might find useful for extending the issued Token's lifetime based on active request traffic?

Thanks again.

---

Regards, Howard Hoffman

Answer 3

In the case of WIF:

The token from ACS is only used once - afterwards it gets exchanged by a session token. By default this session token will have the same life time as the bootstrap token.

You can control the life time of the session token (including sliding expiration) using the WIF APIs.

---

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

Answer 4

Hi HowardH,

I guess that you're referring to this article by Vittorio link, right?

We're in the same situation and I just want to check with you if you found yourself in a rat hole or if you found a good solution?

 

BR,

Max.

Answer 5

Max -

I wound up using something close to what Vittorio outlined at the top of that link, yes, and also in his book.  We implemented a SessionAuthenticationModule_SessionSecurtityTokenReceived method to create a new SessionSecurityToken.  I got it working to the point where login redirects did not hit you every xx minutes while you were actively working.  The project was moth balled before I could test it really hard.  That said, at a minimum the approach looks promising.

HTH,

Howard

---

Regards, Howard Hoffman

Answer 6

Code please... pretty please. :)

Answer 7

I'm using Windows Azure Access Control 2.0, and have been toying with the code in the article.  It seems as if I can get the token to slide the first time, but each additional time results in the following exception:

ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.

Even though the cookie was re-issued, it doesn't look like it was properly done so.  I am setting the sessionTokenRequirement to a few hours in the meantime.