AD FS + Windows Integrated Authentication = Trap for the unwary

There is a quirk in the use of AD FS in its default intranet mode that may come as a surprise to the unwary user.

By default, AD FS sets up the Federation Server to take Windows Integrated authentication; out of the box, it also installs client certificate authentication, but you have to actively enable that by editing the root logon page at  /adfs/ls/clientlogon.aspx

<%@ Page language="c#" AutoEventWireup="false" ValidateRequest="false" %>
<%@ OutputCache Location="None" %>
<% Context.Response.Redirect("auth/integrated/"+Context.Request.Url.Query); %>

to do something other than redirect to the Integrated authentication page.

Now, the interesting thing about Windows Integrated authentication is that having authenticated explictly, your browser is already doing single sign-on (SSO) on your behalf every time you touch an authenticated URL. 

So, having authenticated once to the Federation Service, you are henceforth silently re-authenticated for the rest of the browser session.

"What has this got to do with AD FS?" you may be asking.

Well, AD FS is not only an SSO mechanism; for applications spread across many hosts, it also offers a single sign-off capability.

So let's talk our way through what goes on when all of these are happening at once

1. You go to an AD FS protected application
2. It redirects you to the Federation Server
3. That does integrated authentication, popping up a dialog box at the browser
4. Having logged on, you're redirected back to the application
5. Later, you log off that application -- AD FS directs you back to the Federation Server
6. The Federation Server sends you a page that removes its session cookies, and contains images whose URLs are part of AD FS on the application, so they can remove the session cookies
7. Now you go back to the application page, and--
8. AD FS redirects you to the Federation server which--
9. Silently reauthenticates you and sends you back to the application
   

Step 9 may come as a surprise to the unwary -- unless you have some obvious indication in the web application (such as a last sign-on time), the log-off appears not to have happened.

This is not a bug -- it is an inevitable consequence of an old SSO model with no sign-out capability being used to bootstrap the new federation system; and will happen with any silent re-authentication scheme (such as the alternative authentication mechanism provided in the install, which uses client certificates).

When re-authentication is not silent -- explicit form driven authentication at a Federation Service Proxy, for example -- step 9 is blatantly obvious. This may lull the user into complacency.