Authentication lifetime with WS-Federation via ADFS and WIF

3
votes

Some background

I work on an ASP.NET MVC web application which implements federated authentication using WIF.
For reasons beyond my control, I am forced to use a proxy STS which, on the one hand, serves as the IdP for my MVC app, but at the same time it implements it's own federated authentication via an ADFS server.
This way, the user authentication process in the MVC application looks like this:

  1. User enters MVC application.
  2. The application redirects the user to the proxy STS for authentication.
  3. The proxy STS redirects the user to the ADFS server for authentication.
  4. The ADFS server authenticates the user and redirects back to the proxy STS.
  5. The proxy STS redirects the user back to the application, with the same authentication info which the ADFS server issued.

The ADFS server is not something I have direct access to (in terms of management), whereas the proxy STS is just a little service (implemented using this tutorial) which I control fully.

The problem (and what I tried to do to solve it)

Using the above setup, I noticed that the users' authentication wears off after about an hour, and then they need to be re-authenticated, so now I'm looking for a way to extend the authentication lifetime.
As of my understanding, it should be enough to extend the lifetime of the security token issued by the proxy STS, which I did. But it didn't solve the problem - the users still needed to be re-authenticated frequently.
So I tried doing the following things hoping it would help:

  1. Setting the persistentCookiesOnPassiveRedirects option to true in the MVC application's ws-federation configuration with a 1-week long expiry time (to make sure that the auth cookie is not being lost due to session expiry).
  2. Setting the HTTP session lifetime in the MVC app to last a week (to make sure that the security token is not being lost on the server side due to session expiry).
  3. Setting the security token lifetime for tokens issued by the proxy STS to 1 week (which I made sure is being applied by examining the security tokens received by the MVC app).
  4. Doing the things described in bullets 1 and 2 on the proxy STS as well.
  5. Setting the IIS auto app-pool recycling time for the MVC app's application pool to be once a week.

None of the above didn't seem to solve the problem, but then I tried:

  1. Setting the security token lifetime for tokens issued by the ADFS server to 8 hours.

As a result, the authentication duration got longer, even as much as 10-11 hours.

The question

What controls the authentication duration with WS-Federation in the above scenario?
Which of the above things that I tried should really be relevant to my issue, and which should not affect it at all (specifically, I would like to understand whether the ADFS token lifetime should really have any effect, and if so - why, or did I just have bad luck with my tests, and it was really something else that might have helped with the issue)?

Thanks in advance!

1
asp.netauthenticationwifadfsws-federation
stackoverflow.com/q/14867613/9922 – rbrayb

1 Answers

1
votes

You have hit a lot of relevant parameters. I will talk about the WIF/.NET part and SAML Tokens only. Not about Pool recycling etc. They are different topics. You will have to take a look at the XML in the SAML messages and Tokens if you really want to control this.

One of the problems is that there are differences between SAML1 and SAML2 Tokens. Besides that some validity timestamps are in the SAML Protocol, which is not used between WIF and an IdP.

Summarized:
It appears that WIF uses Conditions for the SessionToken. That is the only thing available in SAML 1.1. OK there.
SecurityTokenHandler.ValidateToken(token) calls DetectReplayedTokens(). The SecurityTokenHandler.DetectReplayedTokens(SecurityToken) method verifies the validity if the incoming Token (SubjectConfirmationData @NotOnOrAfter). It is not present in SAML 1.1 there WIF uses Conditions@NotOnOrAfter. This is essentially correct for Replay detection in SAML 2. Somewhat silly (too broad, too long) for SAML1.1.

Applications can (and do) override this behavior in TokenHandler(s) or in events of WSFAM and SesAM. See for instance Vittorio about Sliding Expiration.