There is a subtle (breaking) change of behavior between WIF 1.0 and .NET 4.5.
The IIdentity interface has the IsAuthenticated property. This is typically set to true whenever you deal with implementations of that interface, e.g as soon as you set the Name property of GenericIdentity, IsAuthenticated is automatically set to true. IIRC in WIF, as soon as a ClaimsIdentity had a claim, IsAuthenticated was set to true.
This has changed in .NET 4.5. It is now possible to create a ClaimsIdentity that has claims, but having IsAuthenticated set to false. Actually this is the default now, when you new up ClaimsIdentity like this:
var id = new ClaimsIdentity(claims);
To have IsAuthenticated set to true, you need to specify an authentication type in the ctor:
var id = new ClaimsIdentity(claims, “Custom”);
I am mentioning this, because I just spent 2 hours looking at code that was giving me authorization errors all over the place. In the end I found out that the security token handler (which was ported from WIF) did not set the authentication method resulting in an non-authenticated identity, which of course in turn made authorization fail in later stages.
HTH
leastprivilege.com 
Dominick, is this by design or is it an accidental. I am a bit ambivalent as to ideally what it should be as I do not have enough detail as to the value of not setting it to true if you have claims. I certainly can see the validity of setting it to true if you have claims. Only thing I can see is that you could have non authenticating claims but the real question is what is the business value?
Well – there might be situations where you want to describe an anonymous user using claims.
It is just that the default behavior has changed.
I agree with what you proposed as a business value option. Yes you could have a default set of claims for anonymous users. But as a workflow option how would this make sense? Typically you go to a relying party, then go to sts and then are presented with a logon screen unless domain level authentication and you put your credentials in and then either get authenticated but you would not normally get authenticated as anonymous missing a logon attempt rather you would be prompted with login failed. So I am looking for a real workflow reality to depict the anonymous situation. I guess the logon screen could present you with a guest check box option and then you get default claims and get routed back to relying party.
There isn’t necessarily an STS involved…anyhow. I wrote this piece because it might hurt you when upgrading.
I currently do not have a business case for it.
One other thing and I did not know where to email you on this but I have a situation where we might need a network topology to support Azure and cloud based SAAS solutions that can be used by various corporations then each corporation might have an application installed onto their private network where those applications might be relying parties but behind the DMZ. How could we setup single sign on across all applications meaning in the private network of each corp + azure and single point of authentication using custom level store and domain level authentication using ADFS2. I have been thinking about this a bit. More importantly right now is there something other than ACS that would provide the ability to authenticate against custom store and active directory as well as a mixed solution. I think ACS does this only. Is that correct? Next and final question is, how do you feel about the viability of Forefront to act as a UAG for folks in the public network being authenticated against the active directory using direct access?
@Michael De Marco: Actually I have almost the same problem and no solution, with a small difference compared to your topology: one Silverlight Application and a WCF-Routing in DMZ for changing the protocol.
@Dominik Baier: It’s possible to have a passive and an active Authentication in this scenario?
As a bit different thing, is there a possibility to set given token (eg. session token) as invalid? Some kind of logout functionality?
You need to clear the cookie. I think FAM.SignOut or SAM.SignOut will do that.
Do you mean FAM or SAM from the FederatedAuthentication class? Because both are null in there. Should I somehow link IdentityModel with either SAM or FAM in the web.config?
sure, the FAM must be a registered module.
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
// clear local cookie
fam.SignOut(false);
@Michael – what exactly is your question?
I have no experience with forefront and direct access. ADFS only does Windows auth – for custom stores you need a federated STS that deals with that custom store.
Thank you so, so much for this post! Was doing my head in trying to work out why AuthenticateSessionSecurityToken wasn’t acting like I thought it should
After migrating my old OAuth2AuthenticationModule (WIF Extension CTP – Azure OAuth2 sample) to WIF 4.5, ClaimsIdentity wasn’t automaticaly authenticated anymore after setting the claims.
Found your post and you saved my day :)
Thanks you.
Do you know wich Authentication Types are considered valid? I could not find any information on this topic.
Whatever you want.