Simple claims transformation and caching w/ windows authentication

Question

For the past few days I\'ve been reading about the windows identity foundation and how it\'s so good and flexible and built right into .net 4.5. Despite going over dozens of

Answer 1

This answer is intended to provide further clarification on John's answer above after experiencing several frustrating days trying to solve some similar problems.

1. ClaimsPrincipalHttpModule

As John discovered, if you are using Windows Auth or Forms Auth, ASP.NET will not automatically invoke your ClaimsAuthenticationManager (it is not a Federated scenario). You must do so yourself after ASP.NET has authenticated the user. Using the ClaimsPrincipalHttpModule, which used to be part of IdentityModel, will effectively ensure this occurs.

However, exercise caution using this module. It was removed for a reason. My theory as to why it was removed from IdentityModel is because it does not play nicely if you host WCF services in your ASP.NET app and have aspNetCompatibilityEnabled=true. It will cause your WCF authentication to break (the module will execute BEFORE the WCF pipeline and my experience is that your WCF clients will no longer be able to properly authenticate - I've confirmed this when using Windows Auth).

If you are hosting WCF services in this scenario you must somehow ensure that the ClaimsAuthenticationManager is only invoked for non-WCF requests. For WCF requests, it seems you have to rely on the WCF pipeline to do so (). The easiest fix is to simply turn off aspNetCompatibilityEnabled. If this is not an option, you should not use ClaimsPrincipalHttpModule but must somehow examine the incoming request and only invoke the ClaimsAuthenticationManager if the request is not destined for WCF.

2. Safe handle error (ObjectDisposedException)

This occurs if you create a SessionSecurityToken that is based on a WindowsIdentity. The SessionAuthenticationModule has special logic to handle WindowsIdentity claims read from a SessionSecurityToken and will attempt to rehydrate the WindowsIdentity using data that is no longer valid. (I'm not sure of the circumstances in which it would work but it consistently failed in all the scenarios I tested). Thus, as John explained, the lesson here is that when attempting to use WIF with Windows auth, SessionSecurityTokens should not be created from a WindowsPrincipal (or more correctly a WindowsIdentity). Any other type of transformed ClaimsPrincipal should be fine.