Non-Supporting ASP.NET Applications and ADFS v2.0

Question

This article made me wonder what would happen to ASP.NET applications with no complaints when you combined them with ADFS through FedUtil.

The article assumes that the key to this work is the inclusion of Claims in the Windows Token Service (C2WTS). This service effectively turns an ADFS token into a Windows token.

So, I built a fast ASP.NET application using Windows authentication, launched FedUtil, and I can authenticate using ADFS using either Windows ADFS authentication or StarterSTS. The problem is that C2WTS is not working, so it works, although I expected it to not.

Obviously, you do not have access to the claim objects inside the application, but otherwise it works without problems.

This, however, causes a problem. How do you exit ADFS since you do not have access to FederatedPassiveSignOut, etc.?

Are tokens sent to the app?

Is it just ignoring them, not throwing any exceptions?

Does C2WTS need to be part of the image?

Did I miss something?

Answer 1

Responding to other forums, Steve Syfuhs replied:

FedUtil modifies the web.config file, so the authentication method is “None” and inserts some handlers very early in the web request to see if the session exists, and if one session is not created, redirecting it to the specified STS, STS does this, and passes token back to the site. Another handler receives the token and builds the IClaimsPrincipal object based on the token. The Thread.CurrentPrincipal object is set to IClaimsPrincipal. Thus, Windows authentication does NOT occur in the web application (but it is in ADFS).

OWA (like all well-built web applications) looks at Thread.CurrentPrincipal to identify the user. As long as the values ​​provided by STS are in line with OWA's expectations, OWA is happy. Some claims are available through Thread.CurrentPrincipal, for example, the Name requirement, which OWA uses to get the username. C2WTS was created to act as a strip between an application that understands the claims and an application that does not create a Windows token, and attaches it to the user's session. OWA needs to be called in Active Directory to get certain bits of information, and this is done through Windows authentication, and therefore it needs a Windows token.

In this case, there is no way to exit 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 statement page, which is https: // adfsserver / adfs / ls /? Wa = wsignout1.0 and will exit ADFS.

Update:

Just for documentation for others:

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

• Access to the objects of claims is absent.
• You need to translate your own input.
• There is something "different" in the metadata of the federation. You cannot add an application as an RP to ADFS through a URL. You must use the file import mechanism. This means that there is no way to update metadata, so if there are any changes to the RP that you must delete and reconfigure.