I've seen this error happen a few times to myself and others so I thought I would share the likely culprit. The scenario is, you set up claims authentication in SharePoint 2010...and you're pretty sure you've configured everything correctly. :-) When you actually try and navigate to the site though you may get the standard ASP.NET error page that says something along the lines of a TrustedMissingIdentityClaimSource error (assuming you have custom errors turned off). Most frequently I've seen this error when you have configured EmailAddress to be the identity claim, but the person you are trying to log in with does not have an email address in Active Directory (or whatever directory you're using). It can be confusing of course because you see yourself getting redirected to ADFS (for purposes of this conversation, could be any IP-STS), you see that you've been authenticated there, but then SharePoint blows up. It serves as a reminder as the difference between who I am (the identity you log in with), and things about me (attributes like EmailAddress and other claims that can be used for permissions provisioning now).
So, if you get this error, the first thing I would recommend checking is whether your user account that you logged in with has a value in the identity claim it is expecting. Remember too, if there's no value in that attribute, the claim will typically not even get sent over to SharePoint (i.e. as an empty string value for example).
Steve - great posts, here and with the end-to-end config guide.
A few questions regarding claims configured to use EmailAddress as the Identity Claim:
I have a user set as the Primary Site Collection Admin, and have confirmed an email address exists for the user.
Note that the email address has been changed at a point during the Web Application setup & config process, from firstname.lastname@example.org to email@example.com.
When selecting the user account in the People Picker to deisgnate as SIte Collection Admin, simply searched for the term "email2," which showed one entry in Active Directory, and one from the SAML feed... selected the one from the SAML feed.
In both instances, below, I have provided the same domain\user credentials in the logon window:
Access the site using Windows(NTLM) Auth, and I am able to successfully access the site with admin rights, but "My Settings" shows my email address as firstname.lastname@example.org (old email address)
Access the site using SAML Auth, and I get "Access Denied" for current user email@example.com (correct/new email address)
So unsure why:
1 - The same user account can access SP as Windows Auth, but not as SAML Auth
2 - SP doesn't see the updated email address that appears in my AD user properties
How often does SP look back at AD to validate/sync the values in the various fields from an SP user with the AD user? Can I manually tell it to update? Is this through User Profile Sync (do I need to set this up separately?)
Thanks for any direction you can provide!
Also, if you get "this error" (TrustedMissingIdentityClaimSource Error), what's the second thing you'd check, after you've verified that the account that you logged in with DOES have a value in the identity claim it is expecting...?
From the ULS Viewer:
System.Web.HttpException: The file '/_layouts/_login/default.aspx' does not exist.
Unknown SPRequest error occurred. More information: 0x80070005
Leaving Monitored Scope (Request (GET:sptest.resource.com/.../default.aspx)). Execution Time=24.2155776781686
So to answer my own question... the second thing you check (after you've verified that the account that you logged in with DOES have a value in the identity claim it is expecting) is to confirm you're actually PASSING said value(s) all the way to SharePoint.
In our example, you could successfully get:
From RESOURCE browser, to SP in RESOURCE Forest, using RESOURCE Windows Credentials
From RESOURCE browser, to RESOURCE Forest ADFS, to SP in RESOURCE Forest, using RESOURCE SAML Claim
From ACCOUNT browser, to RESOURCE Forest ADFS, using ACCOUNT SAML Claim, but Fails at SP, throwing an error about "An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm"
We seemed to have missed the step to configure the Claim Rules on the RESOURCE Relying Party Trust to pass-through the email address and role information.
Check 1 - make sure the account that you logged in with DOES have a value in the identity claim it is expecting
Check 2 - make sure that the value is making it all the way through to the Consuming Party.
I also updated the emailaddress in AD properties later and SP doesnt seem to be getting it.
Any way to fire update to get it ?
All the comments above are more reasons why email address should not be used as the identity claim for AD sources IMO. UPN is guaranteed unique and guaranteed to exist on an AD source. It is even formatted like an email address.