Directory Programming .NET

We are using ADFS as our SSO solution.  When a user logs off they are directed to the signout.aspx page fine.  If the press the back button they request the previous page (i.e. Default.aspx) but directed to the DiscoverClientRealm.aspx page (which is what I would expect).  However, if they press the back button again they make the same request Default.aspx except this time they are successfully authenticated and allowed to enter the site?  How do I prevent this from happening?  I have tried clearing cookies and such on the signout.aspx and DiscoverClientRealm.aspx pages but nothing seems to prevent the user from getting back into the site when pressing the back button twice.

Are you sure this isn't an issue with the page being served from local browser cache?  You might try setting the Expires header to 0 on all your dynamic content pages to ensure that the browser never caches them.

You should not be seeing HRD (realm discovery) over and over.  The idea with that is that it is done once and then you don't bug the user about it again.  The _lsrealm cookie is persistent, so it should stay on the user's machine for a month before it expires.  I'd recommend not clearing that if you are.

Basically, the signout page should clear everything you need cleared without you modifying the code.

Thanks for the response. 

All of our pages have the code to prevent caching on the clients machine.  We have removed any code that clears cookies and we still see the issue.

User logs in and goes to Default.aspx

User logs out and goes through the signout.aspx page.

User presses the back button which tries to go navigate back to the Default.aspx page, but instead the DiscoverClientRealm.aspx page is called and rendered out to the client.

User presses the back button again, which againg tries to navigate back to Default.aspx, but this time they are reauthenticated and allowed to enter the site.

We are now investigating adding our own cookie to keep up with the user to ensure that they have successfully logged in again if they have previously logged out.  Can you think of any other suggestions?

 

I'd suggest getting a trace of the request and response headers using IEHttpHeaders or Fiddler to ensure that you have an understanding of what exactly is happening here.  If you want, you can post those here and I'll take a look to try to interpret.

I don't understand why you would be prompted again for HRD after a successful login or why a valid cookie would be sent again.  I suppose if the form post containing the SAML token for your app got posted to your app again, then the login could be processed from scratch and might trigger this.  The headers would show if that is what happened.

Joe,

Here is our scenario.  Account partner logs in.  They post their SAML to us.  We accept the SAML (and apparently updating it a bit with the authentication pieces) and redirect them to our website.  The user then logs out of the system and we redirect them to the adfs signout.aspx page.  We modified this page to get a url from our appsettings, appending /?wa=signoutcleanup1.0, and then setting an image to this path.  On this page the user can press the back button twice (or choose from the dropdown next to the navigation buttons to go back in history 2 pages) and it the request is reposted and the user is validated.  Is there something we are missing in this process?

I see now.  It wasn't clear to me that the browser POST was being executed again.  That does complicate things a bit.

Just to erase a little bit of the fuzziness of what's going on, what happens when the Account Partner/IdP token is posted to the RP FS is that it reads the token, validates the signature, determines if the token (as identified by the realm identifier) was signed by a certificate configured as be associated with that partner and then also validates the timestamps in the token (notBefore and notOnOrAfter).  If the current time falls within that range, the token is accepted.  Then the FS performs an transformations required on the claims and issues a new token addressed to the requested application which is signed by its own token signing certificate.

Then, the browser posts the new token to the app itself.  This way, the app only has to trust tokens issued by the RP instead of needing to potentially allow tokens signed by lots of different providers.  The RP acts as a broker to establish the trust and "normalize" different claims coming from different partners into a set that the application can understand.

The logout function clears all the cookies that are issued by the various parties (the IdP FS, the RP FS and the app).  However, if one of the raw WS-Fed form post values is actually re-posted to the destination FS AND the timestamps are still valid in the signed token, the token will be accepted and a new cookie will be generated.

There may not be much that can be done about this if the back button cannot be prevented from submitting the form post again.

That said, it may be possible to do something on the web app level.  If you had an overall forms auth set up for the application that could accept ADFS login and issue a forms auth ticket, you might be able to integrate that with an overall ADFS logout so that only your forms auth ticket would remain.  If the FS was then configured to issue tokens that were only good for a brief time, a re-post of the same SAML token would be rejected by the app after it expires.

This is just off the top of my head and I'm not totally sure if it would work or if there would be additional complications that arose from it, but it might be an idea to work with.  I'm not sure if there is any way you can prevent the browser from actually submitting the POST again unfortunately.  It would be nice if there was just some header you could configure in IIS on the FS that would prevent this.  Maybe there is and my lack of knowledge of browser caching details is the limiting factor here.  :)

Thanks!

We have thought about integrating this with forms auth and may pursue that if we can't find a better solution.  So far we have reduced the token time down to 1 minute in the application but ADFS has a built in 5 minute buffer so this is really 6 minutes.  Not a lot of time to post the SAML again, but still enough to worry our clients.

The 5 minute buffer is a feature to allow for clock skew.  ADFS, like nearly all other distributed authentication schemes, relies on synchronized clocks to work, but sometimes the clocks drift anyway.  The 5 minute buffer is an industry standard amount of "fudge" to allow, similar to the default amount of skew allowed for Kerb auth in Windows.

I actually have a vendor we work with that doesn't allow any skew at all and started rejecting tokens from us when one of the servers in my load balancer drifted a few seconds into the future due to a VMWare glitch (or possibility some poor operations by someone :)).  Generally I'm glad the the fudge factor is there.

It would be nice if the agent could reject tokens it has already seen as they also have a unique ID in them, but it does not appear to do that currently.

The other thing I don't really know about yet is if the new Geneva agent handles this differently/better.  I haven't had enough time to play with it yet.  It might be something to look at though.