Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > Claims-aware web application sign-out URL for ADFS and WAP publishing
April 01
Claims-aware web application sign-out URL for ADFS and WAP publishing

If you implement Web Application Proxy (WAP, the reverse HTTPS proxy) with AD FS (Active Directory Federation Services) authentication and publish a claims aware web application, you may like to provide users with a sign-out option for passive clients (browsers). This is a muss in case you allow for persistent SSO, because then the ADFS cookies are persistent, stored on the client computer harddrives even after users close their browsers. The cookies are valid for the whole one day, which might be a lot.

For the explanations, I will assume a web application at the public URL and the AD FS farm published with WAP at public URL. We have two hostnames, in the cookie world usually called domains. But I will rather stick to the term hostname as it is clearer to readers by my record.


The users receive three sets of cookies. One set of cookies comes from the ADFS server itself, bound to the domain/hostname. These authenticate you against the AD FS server in case you come to one of its authentication endpoints again so that you do not need to type your password and submit the ADFS login form again. In case of persistent SSO or KMSI (keep-me-signed-in) these are the cookies which are set as persistent.

After you authenticate with ADFS for the first time, you get claims token, but yet before you pass it through WAP to the web application, you are redirected back to WAP (using the actual web application's host name to authenticat against the WAP proxy. This uses simple GET method and cookie-less authentication with URI token called authToken.

WAP replaces the URI authToken with another cookie of its own. The WAP cookie is bound to the published web application hostname So that any further requests to web application URIs bring the WAP cookie as well and WAP does not need to redirect you to ADFS anymore.

Then you are allowed to pass the claims token to the actual web application. When this claims token is accepted, it is also replaced with web application's own cookies generated by the identity foundation. These are also bound to the web application's host name

The cookie for WAP is session cookie only. It gets discarded when closing browser process. The web application cookies are also session cookies usually. The only exception would be if the web application decides otherwise, but it depends on the web application.

In effect, we have three sets of cookies bound to two different hostnames of and If you point your browser to a hostname, only the cookies bound to that hostname are sent. Thus if a web site or ADFS wants to remove/expire a cookie (sign you out), you must point your browser explicitly to the correct hostname or be redirected to the hostname.

Sign-out from both the web application, WAP and AD FS in a single URI

Users navigate through the web application so their browser points most of the time to the web aplication hostname Thus if we want to provide a sign-off link or button, we must customize the web application and add the web control on one of its pages. It can be a simple HTML A anchor (link).

web application hostname:
adfs host name:
sign-out link:

This URI points first to the web application root and cleans-up its own cookies. The wreply parameter instructs the application to redirect the user afterwards to the ADFS URI for its own cookie cleanup. This way you log off from both the web application and ADFS as well.



There are no comments for this post.

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *