Non-claims-enabled ASP.NET applications and ADFS v2.0

This article got me thinking about what would happen with non-claims enabled ASP.NET applications when you federated them with ADFS via FedUtil.

The article suggests that the key to getting this working is to turn on the Claims to Windows Token Service (C2WTS). This service effectively turns an ADFS token into a Windows token.

So I built a quick ASP.NET application using Windows authentication, ran FedUtil and I can authenticate with ADFS using either the ADFS Windows authentication or StarterSTS. The problem is that C2WTS isn't running so i开发者_JAVA技巧t works although I expected that it wouldn't.

Obviously you have no access to the claims objects inside the application but otherwise it works with no problems.

This does, however, raise a problem. How do you sign out from ADFS since you have no access to FederatedPassiveSignOut etc?

Are tokens being sent to the application?

Is it just ignoring them without throwing any exceptions?

Does C2WTS need to be part of the picture?

Have I missed something?

Asking on other forums, Steve Syfuhs replied:

FedUtil modifies the web.config so the authentication method is 'None', and inserts some handlers very early in the web request to see if a session exists, and if one doesn't a session is created by redirecting to the specified STS, the STS does it's thing, and passes a token back to the site. Another handler receives the token and builds an IClaimsPrincipal object based on the token. The Thread.CurrentPrincipal object is set to the IClaimsPrincipal. As such, Windows Authentication is NOT happening in the web application (but it is in ADFS).

OWA (as should all well built web applications) looks into Thread.CurrentPrincipal for the identity of the user. As long as the values provided by the STS match whatever OWA is expecting, OWA is happy. Certain claims are available through the Thread.CurrentPrincipal, such as the Name claim, which is what OWA uses to get the user name. C2WTS was created to act as a shim between an application that understands Claims and an application that doesn't by creating a Windows Token and attaching it to the user's session. OWA needs to call into Active Directory to get certain bits of information, and it does it through Windows Authentication, and therefore needs a Windows Token.

In this instance there is no way to sign out of ADFS, but you can still kill the session in OWA or your custom application by deleting cookies. In a custom web application you can link to the ADFS signout page, which is https://adfsserver/adfs/ls/?wa=wsignout1.0 and that will sign out of ADFS.

Update:

Just to document for others:

This approach works in terms of outsourcing the authentication but there are three problems:

• There is no access to the claims objects.
• You have to roll your own sign-out.
• There is something “different” about the Federation Metadata. You cannot add the application as a RP in ADFS via the URL. You have to use the import file mechanism. This means that there is no way to update the metadata so if there are any changes to the RP you have to delete and re-configure.