Hey all, there has been a potential issue that's recently come to light for folks that have only applied SharePoint 2010 SP1 but not the June 2011 CU. What you will find after doing this is that the people picker will no longer work for your SAML claims users. You can still add claims via the type in control by typing in a claim value and clicking the resolve button. However, any and all names you enter via the people picker DO NOT resolve. You can get back into a good state by applying the June CU, at which point the out of the box provider for SAML will work again in the people picker. Of course, if you are using a custom claims provider for the default provider then you will not be affected by this issue.
There are a couple of other potential issues I'm still looking at right now that showed up after applying SP1 that the June CU did not fix; these are also both related to SAML authenticated sites only, for mobile devices and programmatic access. As I am able to flesh out additional details about this I will post findings on this blog as warranted.
Seems to be a lot of people with problems related to the people picker in general, post-June Cumulative.
are you saying that the People Picker does support validating SAML claims users (using the built-in provider)? [when it's not broken by SP1]
I've just started reading into Claims/SAML auth and came across this page:
which seems to suggest (in the Architecture section) that Claims/SAML accounts appear validated (underlined) but in fact aren't.
Can you pleae clarify?
BTW you've had a great burst of articles on this stuff, keep it up!
Hi Craig, the out of the box behavior is that SAML claim values in people picker are "resolved", not "validated". An important distinction of course. When you can't even resolve them though (as described in the post above), you are effectively dead in the water in terms of being able to grant users permission to a site.
I configured Tivoli Federated Identity Manager (TFIM) as a trusted identity provider in SharePoint. I can see (via trace) the SAML token being returned from TFIM and a claim being generated and the FedAuth cookie. Would you know why after the cookie is issued I am redirected back to the sign-in page?
Here is the browser URL after authentication and cookie issued:
I don't know why I'm not redirect the the sites default.aspx, I am not using any custom sign-in or default pages.