將Live ID中的Azure ACS nameidentifier與已知用戶列表匹配？

Question

從單純在stackoverflow上發佈的問題來判斷，Azure ACS似乎讓很多實施者失望，因爲它無法爲Windows Live ID用戶提供電子郵件地址。這不僅在註冊新成員方面有用，而且在認證返回成員時也是如此。也許後者的目的仍然可以實現，沒有一些明確的過程，即成員將身份提供者證書連接到他們的賬戶？

ACS爲Live ID用戶提供的「nameidentifier」聲明可能與已註冊會員的正確編碼電子郵件地址匹配嗎？這是我設想的過程：

1. 訪客登記上依賴方網站不通過ACS認證。會員記錄存儲在一個電子郵件地址中，該電子郵件地址恰好也通過Live ID註冊。
2. 網站散列使用實時ID特定的散列函數提供電子郵件地址，並存儲除原始地址以外的地址，以免用戶可能使用Live ID進行身份驗證。
3. 會員返回時沒有識別cookie，並選擇通過ACS通過Live ID憑證進行身份驗證。
4. ACS返回Live ID的nameidentifier聲明。
5. 網站將nameidentifier與步驟2中的哈希地址相匹配。
6. 網站登錄成員。

有誰知道這樣的散列函數可能公開嗎？

乾杯

BillVo

Answer 1

我不認爲這是可能的。每個ACS名稱空間的名稱標識符不同。這是防止多個網站進行協作（勾結）並跟蹤用戶的有意設計選擇。你沒有辦法生成一個與名稱標識符相匹配的LiveID散列（如果我理解你的建議）。如果我能預測它會是什麼，它會使名稱標識變得毫無用處。具體而言，我可以通過預測所有我想與之共謀的潛在網站來「反向」散列，我們可以共享這些信息，從而爲存在提供理由。

對於LiveID，很容易將ACS登錄與用戶配置文件相關聯：您先通過ACS登錄用戶，然後在您的站點上註冊。那時，您可以將您的本地配置文件或ACS中的規則存儲在用戶的電子郵件地址中。我更喜歡前者（即如果我看到名稱標識符X，則查找數據源中的配置文件並知道用戶的電子郵件地址）。但是，在ACS中提供一個規則來處理X名稱標識符的傳入聲明併產生用戶提供的電子郵件地址的傳出聲明並非不可能。這樣做的不利之處在於你在ACS中準備了大量的規則來適應這種情況。

Answer 2

dunnry說的一切！儘管如此，我認爲Live ID在這裏做的是正確的事情 - 當用戶提供Live ID（註冊）的詳細信息時，它不同意與其他人分享這些信息，並且不應該共享這些信息使用任何網站/應用程序的先決條件。

ACS和Live ID爲您提供了一種重複唯一標識用戶的機制，然後您應該向用戶詢問您需要的任何其他細節並自行存儲它們。例如，Google在沒有理由這樣做的情況下，正在採取措施遠程共享用戶的姓名和電子郵件。我已經寫了這個here

Answer 3

你需要使用Windows Live SDK拉用戶配置文件。