2

Judging from questions posted on here on stackoverflow alone, Azure ACS appears to be disappointing many implementers because of its inability to provide an email address for a Windows Live ID user. This would certainly be useful in not only registering new members but also authenticating returning members. Perhaps the latter purpose is still achievable without some explicit process whereby the member connects Identity Provider credentials to their account?

Is it possible that the "nameidentifier" claim which ACS does provide for Live ID users could be matched to the properly-encoded email address of a registered member? This is the process I envision:

  1. Visitor registers on Relying Party website without authenticating via ACS. Member record is stored including an email address which happens to also be registered with Live ID.
  2. Website hashes provided email address using Live ID-specific hash function and stores that in addition to the original address, on the off chance that the user might authenticate with Live ID.
  3. Member returns with no identifying cookie and chooses to authenticate with Live ID credentials via ACS.
  4. ACS returns nameidentifier claim for Live ID.
  5. Website matches nameidentifier to hashed address from step 2.
  6. Website logs in member.

Does anyone know if such a hash function might be publicly available?

Cheers

BillVo

BillVo
  • 565
  • 1
  • 5
  • 20

3 Answers3

5

I don't think this is possible. The name identifier differs per ACS namespace. That was an intentional design choice to prevent multiple websites from collaborating (colluding) and tracking users. You have no way of producing a LiveID hash that will match the nameidentifer claim (if I understand what you are suggesting). It would render the nameidentifier pretty useless if I could predict what it would be. Specifically, I could then "reverse" the hash by predicting all the potential websites I want to collude with and we could share that information, rendering the reason for existence moot.

For LiveIDs, it is easy enough to associate an ACS login with the user profile: You have the user login through ACS first, then register on your site. At that time, you store in either your local profile or in a rule in ACS the user's email address. I prefer the former (i.e. if I see name identifier X, I look up the profile in my data source and know the user's email address). However, it is not impossible to just provision a rule in ACS that takes an incoming claim of X name identifier and produces an outgoing claim of the email address the user supplied. The downside to this is that you are provisioning potentially tons of rules in ACS to accomodate that.

dunnry
  • 6,858
  • 1
  • 20
  • 20
2

Everything that dunnry said!

Seriously though - I think that Live ID does the right thing here - at the time the user provided details to Live ID (registration) it did not agree to share this information with anyone else, and sharing this information should not be a pre-requisite for using any web site/application.

ACS and Live ID provides you with a mechanism to repeatedly uniquely identify the user, you should then ask the user for any other details you require and store them yourself.

Google, for example, is going a step to far sharing the user's name and email when there's no reason to do so. I've written about this here

Yossi Dahan
  • 5,389
  • 2
  • 28
  • 50
0

You need to use the Windows Live SDK to pull the users profile.

Idaho Edokpayi
  • 418
  • 3
  • 11