We are experiencing a weird issue with the Google provider where it sends more than one claim of the "name" type to our server. We map the Google Email claim to the name claim, since email is how we lookup a user's account, however this has created
a serious problem for us, as we now recieve the email address, the name and the name identifier all as a name-type claim. Obviously, our code expects to only receive one claim of a given type, so this creates problems.
ACS only produces only the output claims that your rules ask for. If you want to map only the email address to Name, you should remove any other rules that pass through claim types. For example, consider the following rules:
Rule 1: Pass through "email address", all values, as the output type "name".
Rule 2: Pass through all claim types and values as output claims.
This set of rules will result in two name claims, one with the name and one with the email address. If you only want the email address value in the "name" claim, remove rule 2.
OK, I probably should have been more specific. I have some degree with experience with ACS and with Federated Authentication in general, so this appears to be more than a simple bad mapping issue. Here is our rule set:
One would expect three claims to be returned, one for the identityprovider (Google), one for the nameidentifier (with the Google account id) and one for the name, which should be the user's Gmail address. Instead, we get three values for the name,
one which is correct, one which is a copy of the name identifier, and one which is the user's actual name, unmapped from the email.
I should probably add that a particularly bad third-party vendor "accidentally" made some unauthorized changes to the server while trying to set up their application as a Relaying Party.
What it looks like to me is that one of your rules may not be what the description indicates. Could you have a rule of the following form?
Input claim type: any
Input claim value: any
Output claim type: name
Output claim value: pass through
If not, try hooking up HttpWatch or Fiddler and seeing what the output from ACS looks like. If these values look different in the SAML token on the wire, you may have a local issue such as what Steve suggests.