UPN對某個猜測用戶的聲明在哪裏？

我們有一個輔助AAD與來自主要AAD的猜中用戶。爲來賓用戶生成的令牌似乎缺少upn聲明，但我們依賴upn聲明存在，因爲這是我們用來跨用戶映射用戶的事實。UPN對某個猜測用戶的聲明在哪裏？

據我所知，upn可能缺少猜測的Microsoft Live帳戶，但這些是完整的AAD帳戶，只是在另一個AAD中。微軟的文檔也表明unique_name聲明可能並不是唯一的！

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims

你能告訴我什麼決定了UNIQUE_NAME要求的價值？

這對我們來說是安全嗎？如果不存在upn索賠或者是外部猜測的用戶，那麼這種索賠是否安全？

Guest用戶令牌的內容

{ 
    ..,... 
    "tid": "xxxxxxxx-7ea7-413c-96bc-3f3aba133732", 
    "unique_name": "[email protected]", 
    "ver": "1.0" 
}

普通用戶令牌的內容：

{ 
    ...... 
    "tid": "xxxxxxxx-72d8-4715-b14f-990c93843416", 
    "unique_name": "[email protected]", 
    "upn": "[email protected]", 
    "ver": "1.0"

}

我知道你可能會喜歡我們使用的「OID」，但是這會造成我們由於同一用戶在每個AAD中的價值不同，所以環境之間的問題也會有所不同。

來源

2017-07-12 Daniel Meech

只是想提一下，你是正確的unique_name不是「唯一的」。閱讀[令牌聲明頁面]上的說明（https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims）。 '提供可識別令牌主題的人類可讀值。此值不保證在租戶內是唯一的，並且僅用於顯示目的。「 –

所以我的一個問題是，租戶中的價值是如何計算或確定的？ AAD Admin可以對用戶記錄做些什麼來改變它？作爲一名建築師和喜歡乾淨利落的命名的人，爲什麼這種說法叫做unique_name？ –

我們處於完全相同的情況。到目前爲止，我們已經使用了'unique_name'，但事實證明，這個標識符在所有情況下都不符合UPN的值，例如，對於租戶訪客用戶。我認爲我們的解決方案是在'unique_name'上使用'upn'和fallback，對於進一步的Graph API用戶查詢，查詢所有用戶並檢查'userPrincipalName'和'mail'是否匹配。關於'unique_name'的命名，我個人對閱讀微軟文檔感到非常滿意。 – martinjlowm

代表Azure AD中的訪客用戶的令牌（以及令牌ver==1.0）確實會丟失upn聲明，但會包含您發現的unique_name聲明。這適用於來自其他Azure AD租戶的訪客用戶以及來自外部身份提供者的訪客用戶。

來自其他Azure AD租戶的訪客用戶的unique_name索賠值將是用戶的UPN（如果可用）或以其他方式回退到用戶的電子郵件地址。對於其他類型的訪客用戶，unique_name將採用其他格式的&值。這個想法是，unique_name是來賓用戶的盡力而爲的人類可讀標識符。

在任何情況下，unique_name的值都可以更改，並且在極少數情況下可能會發生衝突。這就是文檔建議不要將其用作主要用戶標識符的原因。 Azure AD系統中推薦的用戶標識是對象標識，或oid。

是的，oid對於同一個人在不同租戶之間會有所不同。但這就是Azure AD租賃模式的一個重點。另一個租戶中的訪客用戶與其「家」租戶中的用戶相比，顯示爲與應用程序完全不同的用戶。如果您想將這兩個用戶映射到一起，那麼您可以使用啓發式技術，如unique_name。

我建議你的文件上feedback.azure.com請求有兩件事情：可以跨租戶識別用戶

可靠的用戶標識符。
有關如何處理AAD中的訪客帳戶的更好文檔。

來源

2017-07-13 18:07:39 dstrockis

UPN對某個猜測用戶的聲明在哪裏？

回答

相關問題