本主題描述外部驗證提供者如何連線到 Microsoft Entra 多重要素驗證 (MFA)。
這很重要
外部驗證提供者目前處於公開預覽狀態。 如需預覽的詳細資訊,請參閱 線上服務的通用授權條款。 在此預覽版中,我們可讓您讓外部驗證提供者與 Microsoft Entra ID 租用戶整合為外部驗證方法 (EAM) 。 EAM 可以滿足存取資源或應用程式之 MFA 需求的第二個因素。 EAM 至少需要 Microsoft Entra ID P1 授權。
當使用者登入時,會評估租用戶原則。 驗證需求是根據使用者嘗試存取的資源來決定。
視其參數而定,多個原則可能會套用至登入。 這些參數包括使用者和群組、應用程式、平台、登入風險層級等等。
根據驗證需求,使用者可能需要使用另一個因素登入,以符合 MFA 需求。 第二個因素需要補充第一個因素的類型。
租戶系統管理員會將 EAM 新增至 Microsoft Entra ID。如果租戶要求使用 MFA 的 EAM,在 Microsoft Entra ID 驗證兩者之後,登入會被視為符合 MFA 要求。
- 在 Microsoft Entra ID 中完成的第一個要素
- 使用 EAM 完成的第二個因素
該驗證符合下列兩種以上方法類型的 MFA 需求:
- 您已知的資訊 (知識)
- 您擁有的物品 (持有)
- 您的某些特徵 (固有)
EAM 會在 Open ID Connect (OIDC) 上實作。 此實作至少需要三個公開面向的端點:
- OIDC 探索端點,如探索提供者元數據中所述
- 有效的 OIDC 驗證端點
- 發佈提供者公開憑證所在的 URL
讓我們進一步了解登入如何與 EAM 搭配運作:
- 使用者嘗試使用密碼等第一個因素登入受 Microsoft Entra ID 保護的應用程式。
- Microsoft Entra ID 判斷需要滿足另一個因素。 例如,條件式存取原則需要多因素身份驗證(MFA)。
- 使用者選擇 EAM 作為第二個因素。
- Microsoft Entra ID 將使用者的瀏覽工作階段重新導向至 EAM URL:
- 此 URL 是從系統管理員在創建 EAM 時配置的探索 URL 中被發現的。
- 應用程式會提供即將過期或已過期的憑證,其中包含識別使用者和租戶的資訊。
- 外部驗證提供者會驗證權杖是否來自 Microsoft Entra ID,並檢查權杖的內容。
- 外部驗證提供者可能會選擇性地呼叫 Microsoft Graph,以擷取使用者的其他資訊。
- 外部驗證提供者會執行它認為必要的任何動作,例如使用某些認證來驗證使用者。
- 外部驗證提供者會將使用者重新導向回具有有效權杖的 Microsoft Entra ID,包括所有必要的宣告。
- Microsoft Entra ID 會驗證權杖的簽章是否來自已設定的外部驗證提供者,然後檢查權杖的內容。
- Microsoft Entra ID 會根據需求驗證存取權杖。
- 如果使用者在驗證成功時符合 MFA 需求。 使用者可能也必須符合其他原則需求。
使用 Microsoft Entra ID 設定新的外部驗證提供者
需要一個用於整合的應用程式,EAM 才能發出 id_token_hint。 應用程式可以透過兩種方式建立:
- 在每個使用外部提供者的租戶中進行建立。
- 作為多租用戶應用程式創建。 特權角色管理員需要授予同意,才能為其租戶啟用整合功能。
多租戶應用程式可降低每個租戶中錯誤配置的可能性。 它還允許提供者在一個地方修改中繼資料,例如修改回覆 URL,而不是要求每個租戶進行相同的更改。
若要設定多租用戶應用程式,提供者管理員必須先:
如果他們還沒有 Microsoft Entra ID 租用戶,請建立一個。
在其租用戶中註冊應用程式。
將應用程式支援的帳戶類型設定為:任何組織目錄中的帳戶(任何 Microsoft Entra ID 租用戶 - 多租用戶)。
將委派的 Microsoft Graph 權限
openid和profile新增至應用程式。請勿在此應用程式中發佈任何範圍。
將外部識別提供者的有效 authorization_endpoint URL 新增至該應用程式,並用作回覆 URL。
注意
提供者發現文件中提供的 authorization_endpoint 應新增為應用程式註冊中的重新導向 URL。 否則,您會收到下列錯誤: ENTRA IDSTS50161:無法驗證外部宣告提供者的授權 URL!
應用程式註冊程序會建立具有數個屬性的應用程式。 我們的案例需要這些屬性。
| 財產 | 說明 |
|---|---|
| 物件識別碼 | 提供者可以使用物件識別碼搭配 Microsoft Graph 來查詢應用程式資訊。 提供者可以使用物件識別碼,以程式設計方式擷取和編輯應用程式資訊。 |
| 申請編號 | 提供者可以使用應用程式識別碼作為其應用程式的 ClientId。 |
| 首頁網址 | 提供者首頁 URL 不會用於任何項目,但在應用程式註冊過程中需要。 |
| 回應網址列表 | 提供者的有效重定向網址。 必須符合為租用戶設定的提供者主機 URL。 其中一個已註冊的回覆 URL 必須與 Microsoft Entra ID 通過 OIDC 探索為主機 URL 擷取的 authorization_endpoint 前綴相符。 |
為每個租戶提供應用程式也是支持整合的一種有效模式。 如果您使用單一租用戶註冊,則租用戶系統管理員必須針對單一租用戶應用程式,使用上表中的屬性建立應用程式註冊。
注意
使用 EAM 的租用戶需要應用程式的管理員同意。 如果未授予同意,當系統管理員嘗試使用 EAM 時,會出現以下錯誤:AADSTS900491:找不到服務主體 <您的應用程式 ID>。
設定選擇性宣告
提供者可以使用 id_token的選擇性宣告來設定更多宣告。
注意
不論應用程式的建立方式為何,提供者都需要為每個雲端環境設定選擇性宣告。 如果多租用戶應用程式用於全域 Azure 和適用於美國政府的 Azure,則每個雲端環境都需要不同的應用程式和應用程式識別碼。
將 EAM 新增至 Microsoft Entra ID
外部識別提供者資訊會儲存在每個租用戶的驗證方法原則中。 提供者資訊會儲存為 externalAuthenticationMethodConfiguration 類型的驗證方法。
每個提供者在政策的列表物件中都有一個條目。 每個項目都必須陳述:
- 如果方法已啟用
- 可以使用方法的內含群組
- 無法使用該方法的排除群組
條件式存取系統管理員可以使用 [需要 MFA 授與] 來建立原則,以設定使用者登入的 MFA 需求。 目前不支援具備驗證強度的外部驗證方法。
如需如何在 Microsoft Entra 系統管理中心新增外部驗證方法的詳細資訊,請參閱 在 Microsoft Entra ID (預覽) 中管理外部驗證方法。
Microsoft Entra ID 與提供者的互動
下一節說明提供者需求,並包含與提供者進行 Microsoft Entra ID 互動的範例。
探索提供者中繼資料
外部識別提供者必須提供 OIDC 探索端點。 此端點可用來取得更多組態資料。 發現網址 必須 使用該 https 方案,且 結尾必須 為 /.well-known/openid-configuration。 此段之後不允許新增路徑段、查詢字串或片段。 完整的發現 URL 必須包含在建立 EAM 時設定的發現 URL 中。
端點會傳回裝載於該處的提供者元數據 JSON 檔 。 端點也必須傳回有效的內容長度標頭。 元資料文件 必須 符合 OpenID Connect Discovery 1.0 (包含勘誤集 2),並包含所有必要的 OIDC 元資料欄位。 下表列出提供者中繼資料中應該存在的資料。 此擴充性案例需要這些值。 JSON 中繼資料文件可能包含詳細資訊。
如需具有提供者元數據值的 OIDC 檔,請參閱 提供者元數據。
| 詮釋資料值 | 值 | 註解 |
|---|---|---|
| 發行者 | 必須是 HTTPS URL。 發行者值 必須 在設定的發行者、探索文件中的發行者值,以及提供者服務簽發的代幣中的聲明之間逐字匹配。 發行器可以包含埠和/或路徑區段,但不得包含查詢參數或片段識別碼。 |
|
| 授權端點 | Microsoft Entra ID 用於授權通訊的端點。 此端點必須列為允許應用程式的其中一個回覆 URL。 | |
| jwks_uri | 其中 Microsoft Entra ID 可找到確認驗證提供者所發出簽章所需的公開金鑰。 該jwks_uri端點必須是 HTTPS 端點,且不得包含查詢參數或片段識別碼。[!注意] JSON Web 金鑰 (JWK) x5c 參數必須存在,才能提供提供的索引鍵 X.509 表示法。 |
|
| 支援的範圍 | openid | 其他值也可能包含在內,但並非必要。 |
| 支援的回應類型 | id_token(驗證令牌) | 其他值也可能包含在內,但並非必要。 |
| 支援的主題類型 | ||
| id_token_簽名演算法值_支援類型 | Microsoft 支援 RS256 | |
| 支援的申請類型 | 一般 | 這個屬性是選擇性的,但如果存在,則應該包含一般值;也可能包含其他值。 |
https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net/v2.0",
"jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
https://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
注意
JWK x5c 參數必須存在,以提供鑰匙的 X.509 表示法。
發現網址與發行者範例
以下範例說明此整合中有效與無效的發現網址及發行者組合。
有效的發現網址與發行者配對
- 探索 URL:
https://example.com/.well-known/openid-configuration
發行人:https://example.com - 探索 URL:
https://example.com:8443/.well-known/openid-configuration
發行人:https://example.com:8443 - 探索 URL:
https://example.com/tenant1/.well-known/openid-configuration
發行人:https://example.com/tenant1
無效的發現網址與發行者範例
- 探索 URL:
https://example.com/.well-known/openid-configuration
發行者:https://example.com:443/(發行者中明確新增預設 HTTPS 埠) - 探索 URL:
https://example.com:443/.well-known/openid-configuration
發行商:https://example.com/(埠碼不匹配) - 探索 URL:
https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
發行者:https://example.com(Discovery URL 中不允許查詢字串)
提供者中繼資料快取
為了改善效能,Microsoft Entra ID 會快取提供者傳回的中繼資料,包括金鑰。 每次 Microsoft Entra ID 與外部識別提供者交談時,提供者中繼資料快取會防止探索呼叫。
此快取每 24 小時(一天)更新一次。 以下是我們建議提供者進行金鑰輪換的方式:
- 在 「jwks_uri」 中發佈 現有的憑證 和新 憑證 。
- 請繼續使用 現有的憑證 簽署,直到Microsoft Entra ID 快取重新整理、過期或更新(每 2 天)。
- 切換至使用 New Cert 簽署。
我們不會發佈金鑰變換的排程。 相依服務必須準備好處理立即和定期的變換。 我們建議使用專為此用途而建置的專用連結庫,例如 azure-activedirectory-identitymodel-extensions-for-dotnet。 如需詳細資訊,請參閱 在 Microsoft Entra ID 中簽署密鑰變換。
發現 Microsoft Entra ID 中繼資料
提供者也需要擷取 Microsoft Entra ID 的公開金鑰,以驗證 Microsoft Entra ID 所發行的權杖。
Microsoft Entra ID 中繼資料發現端點:
- 全域 Azure:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure 專為美國政府打造的解決方案:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - 由 21Vianet 營運的 Microsoft Azure:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
使用從令牌中獲得的公鑰標識符(JSON Web 簽章(JWS) 的“kid”),可以確定應使用從 jwks_uri 屬性擷取的哪個密鑰來驗證 Microsoft Entra ID 令牌的簽章。
驗證 Microsoft Entra ID 核發的權杖
如需如何驗證Microsoft Entra ID 所簽發之令牌的資訊,請參閱 驗證和標識符令牌。 我們的探索中繼資料使用者沒有特別的步驟。
Microsoft的 令牌驗證庫 擁有所有已記載的令牌驗證細節,或者可以通過瀏覽原始程式碼來確定。 如需範例,請參閱 Azure 範例。
驗證成功之後,您可以使用索引承載來取得使用者及其租用戶的詳細資料。
注意
驗證 id_token_hint 很重要,以確保該 id_token_hint 來自 Microsoft 租戶,並且代表您的整合。 應該完整驗證 *id_token_hint*,特別是簽章、簽發者、對象以及其他聲明值。
Microsoft Entra ID 致電外部識別提供者
Microsoft Entra ID 會使用 OIDC 隱含流程 與外部識別提供者通訊。 使用此流程時,會使用提供者的授權端點,以獨佔方式與提供者通訊。 為了讓提供者知道 Microsoft Entra ID 為哪位使用者發出要求,Microsoft Entra ID 會透過 id_token_hint 參數傳入令牌。
此呼叫是透過 POST 要求進行,因為傳遞至提供者的參數清單很大。 大型清單可防止使用限制 GET 要求長度的瀏覽器。
下表列出驗證要求參數。
注意
除非它們列在下表中,否則提供者應該忽略要求中的其他參數。
| 驗證查詢參數 | 值 | 說明 |
|---|---|---|
| 範圍 | openid | |
| 回應類型 | Id_token | 用於隱含流程的值。 |
| 回應模式 | 表單提交 | 我們使用表單 POST 來避免大型 URL 的問題。 我們預期所有參數都會在請求正文中傳送。 |
| 用戶識別碼 | 由外部識別提供者指定給 Microsoft Entra 識別碼的用戶端識別碼,例如 ABCD。 如需詳細資訊,請參閱 外部驗證方法描述。 | |
| 重定向網址 | 外部識別提供者傳送回應(id_token_hint)的重新導向統一資源識別符(URI)。 請參閱此數據表之後的 範例 。 | |
| nonce | Microsoft Entra ID 所產生的隨機字串。 它可以是會話識別碼。 若有提供,則必須在回應中傳回至 Microsoft Entra ID。 | |
| 狀態 | 如果傳入參數,提供者應該在其回應中返回狀態。 Microsoft Entra ID 會使用狀態來保留呼叫的相關內容。 | |
| 識別令牌提示 | 由 Microsoft Entra ID 簽發的終端使用者令牌,並為提供者的利益傳入。 | |
| 主張 | 包含所要求聲明的 JSON 資料塊。 如需此參數格式的詳細資訊,請參閱 OIDC 檔中 的宣告要求參數 ,以及此數據表之後的 範例 。 | |
| 客戶請求識別碼 | 全球唯一識別碼 (GUID) 值 | 提供者可以記錄此值,以協助針對問題進行疑難排解。 |
重新導向 URI 的範例
重新導向統一資源識別項 (URI) 應該向提供者頻外註冊。 可傳送的重新導向 URI 如下:
- 全域 Azure:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure 專為美國政府打造的解決方案:
https://login.microsoftonline.us/common/federation/externalauthprovider - 由 21Vianet 營運的 Microsoft Azure:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
滿足 MFA 的 EAM 範例
以下是 EAM 滿足 MFA 的驗證範例。 此範例可幫助供應者了解 Microsoft Entra ID 所預期的宣告。
Microsoft Entra ID 會使用 acr 和 amr 值的組合進行驗證:
- 用於第二個因素的驗證方法符合 MFA 需求
- 驗證方法在類型上與用於完成 Microsoft Entra ID 登入的第一個驗證因素的方法不同。
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
預設 Id_token_hint 聲明
本節描述在向提供者發出的請求中,作為 id_token_hint 傳遞的 token 的必要內容。 令牌可能包含比下表中列舉的更多的宣告。
| 索賠 | 值 | 說明 |
|---|---|---|
| 國際太空站 | 識別建構和傳回權杖的安全性權杖服務 (STS),以及使用者進行驗證的 Microsoft Entra ID 租用戶。 您的應用程式應該使用宣告中的 GUID 部分來限制能登入應用程式的租用戶集合,若適用。 發行者應符合使用者登入的租戶中的 OIDC 發現 JSON 中繼資料的發行者 URL。 | |
| 澳大利亞元 (AUD) | 應將受眾設定為外部身份提供者的客戶端識別碼,以適用於 Microsoft Entra ID。 | |
| exp (英文) | 過期時間設定為在發行時間之後的短時間內過期,足以避免時間扭曲問題。 由於此令牌並非用於驗證,因此其有效期限沒有理由大幅超過請求的時間。 | |
| iat | 照常設定發行時間。 | |
| tid | 租用戶識別碼用於將租用戶公告給提供者。 它代表使用者所來自的 Microsoft Entra ID 租戶。 | |
| oid | Microsoft 身分識別平台中物件的不可變識別碼。 在此情況下,它是使用者帳戶。 它也可用來安全地執行授權檢查,以及做為資料庫資料表中的索引鍵。 此識別碼可跨應用程式唯一識別使用者。 登入相同使用者的兩個不同應用程式會在 oid 宣告中收到相同的值。 因此,oid 可用於查詢 Microsoft 線上服務,例如 Microsoft Graph。 | |
| 首選使用者名稱 | 提供一個人類可讀的值以識別憑證的對象。 此值不保證是租用戶中的唯一值,並且應該僅用於顯示目的。 | |
| 分支 | 終端使用者在簽發者處的主體識別碼。 權杖宣告資訊的主體,例如應用程式的使用者。 這個值不可變,而且無法重新指派或重複使用。 它可以安全地執行授權檢查,例如在使用權杖存取資源時,並可作為資料庫表中的索引。 由於主體總是存在於 Microsoft Entra ID 所簽發的權杖中,我們建議您在一般用途的授權系統中使用此值。 不過,主體是配對識別碼,對於特定應用程式識別碼而言,這是唯一的。 因此,如果單一使用者使用兩個不同的用戶端標識元登入兩個不同的應用程式,則這些應用程式會收到主體宣告的兩個不同的值。 視您的架構和隱私權需求而定,此結果不一定是您想要的。 另請參閱 oid 宣告(在租戶內的應用程式之間保持不變)。 |
為了防止它被用於提示以外的目的,該權杖被設置為過期狀態。 已簽署的 Token 可以使用已發佈的 Microsoft Entra ID 探索資料進行驗證。
來自 Microsoft Entra ID 的選擇性聲明
如果提供者需要來自 Microsoft Entra ID 的選擇性宣告,您可以為 id_token 設定下列選擇性宣告:given_name、、family_name、 preferred_usernameupn。 如需詳細資訊,請參閱 選擇性宣告。
建議使用主張
Microsoft 建議使用 oid 和 tid 宣告,將提供者端的帳戶與 Azure AD 中的帳戶建立關聯。 這兩個聲明保證對於租用戶中的帳戶來說是獨一無二的。
id_token_hint 的範例
以下是目錄成員的 id_token_hint 範例:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
以下是租戶中賓客使用者的 id_token 提示範例:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
對外部身份提供者的建議行動
我們建議外部識別提供者完成這些步驟。 此清單並不詳盡,且提供者應該在其認為適合時完成其他驗證步驟。
- 依據請求:
- 請確保
redirect_uri已按 Microsoft Entra ID 呼叫外部身份提供者 中的描述發佈。 - 確保設定的發現 URL 使用 HTTPS,結尾
/.well-known/openid-configuration為 ,且不含查詢參數或片段識別碼,且發行者的值與發現文件完全一致。 - 確保 有
client_id給 Microsoft Entra ID 指派的值,例如 ABCD。 - 提供者應先 驗證
id_token_hintMicrosoft Entra ID 所呈現的資訊。
- 請確保
**1. 根據id_token_hint中的說法:
- 他們可以選擇性地呼叫 Microsoft Graph ,以擷取此使用者的其他詳細數據。 id_token_hint中的 oid 和 tid 聲明在這方面很有用。 如需id_token_hint中提供之聲明的詳細資訊,請參閱 預設id_token_hint聲明。
- 然後執行提供者產品所建置以執行的任何其他驗證活動。
- 根據使用者動作的結果和其他因素,提供者接著會建構回應並傳回至 Microsoft Entra ID,如下一節所述。
Microsoft Entra ID 對提供者回應的處理
提供者需要將回應發送至 redirect_uri。 應該在成功的回應上提供下列參數:
| 參數 | 值 | 說明 |
|---|---|---|
| id_token(驗證令牌) | 外部身份提供者所發出的權杖。 | |
| 狀態 | 在要求中傳遞的相同狀態 (如果有的話)。 否則,這個值不應該存在。 |
成功時,提供者會針對使用者發出 id_token。 Microsoft Entra ID 會使用已發佈的 OIDC 中繼資料來驗證權杖是否包含預期的宣告,並執行 OIDC 所需權杖的任何其他驗證。
| 索賠 | 值 | 說明 |
|---|---|---|
| 國際太空站 | 簽發者 – 必須符合提供者的探索中繼資料中的簽發者。 | |
| 澳大利亞元 (AUD) | 對象 – Microsoft Entra ID 用戶端識別碼。 請參閱 外部識別提供者Microsoft Entra ID 呼叫中的client_id。 | |
| exp (英文) | 過期時間 – 如常設定。 | |
| iat | 發行時間 – 如常設定。 | |
| 分支 | 主體 – 必須與所傳送的 id_token_hint 中的 sub 一致,才能初始化此請求。 | |
| nonce | 在請求中傳遞的同一個 nonce。 | |
| ACR | 驗證請求的 ACR 宣告。 此值應該符合傳送至起始此要求之要求中的其中一個值。 應該只傳回一個 ACR 宣告。 如需索賠清單,請參閱 支援的 acr 索賠。 | |
| AMR (抗微生物藥物耐葯 | 驗證中所使用之驗證方法的 amr 宣告。 此值應該以陣列的形式傳回,且應該只傳回一個方法宣告。 如需聲明清單,請參閱 支援的amr聲明。 |
支援的 ACR 聲明
| 索賠 | 備註 |
|---|---|
| 所有權或固有性 | 驗證必須以擁有或固有為基礎的因素進行。 |
| 知識或擁有 | 驗證必須以知識或擁有為基礎的因素進行。 |
| 知識或固有屬性 | 驗證必須以知識或固有為基礎的因素進行。 |
| 知識或擁有或固有性 | 驗證必須透過基於知識、持有或固有的因素方式進行。 |
| 知識 | 驗證必須以知識為基礎的因素進行。 |
| 擁有 | 驗證必須以擁有為基礎的因素進行。 |
| 固有 | 驗證必須以固有為基礎的因素進行。 |
支援的 amr 聲明
| 索賠 | 備註 |
|---|---|
| 臉 | 臉部生物辨識 |
| 菲多 | FIDO2 已被使用 |
| 菲亞特動力科技 | 使用指紋進行生物特徵辨識 |
| 哈哈哈 | 擁有硬體安全金鑰的證明 |
| 光圈 | 使用虹膜掃描進行生物特徵辨識 |
| 一次性密碼 | 單次密碼 |
| 快顯 | 擁有權證明 |
| 視網膜 | 使用視網膜掃描進行生物特徵辨識 |
| SC | 智慧卡 |
| 簡訊 | 傳送文字訊息至已註冊的號碼進行確認 |
| SWK | 確認是否有軟體安全金鑰 |
| 電話 | 透過電話確認 |
| VBM | 使用聲紋進行生物特徵辨識 |
Microsoft Entra ID 需要完成 MFA 驗證才能發出包含 MFA 聲明的權杖。 因此,只有具有不同類型的方法才能滿足第二個因素需求。 如先前所述,可用來滿足第二個因素的不同方法類型是知識、擁有和固有。
Microsoft Entra ID 會根據下表檢查類型映射。
| 索取方法 | 類型 | 備註 |
|---|---|---|
| 臉 | 固有 | 臉部生物辨識 |
| 菲多 | 擁有 | FIDO2 已被使用。 某些實作可能也需要使用生物辨識技術,但擁有方法類型是主要的安全屬性,因此會被映射。 |
| 菲亞特動力科技 | 固有 | 使用指紋進行生物特徵辨識 |
| 哈哈哈 | 擁有 | 擁有硬體安全金鑰的證明 |
| 光圈 | 固有 | 使用虹膜掃描進行生物特徵辨識 |
| 一次性密碼 | 擁有 | 一次性密碼 |
| 快顯 | 擁有 | 擁有權證明 |
| 視網膜 | 固有 | 使用視網膜掃描進行生物特徵辨識 |
| SC | 擁有 | 智慧卡 |
| 簡訊 | 擁有 | 傳送文字訊息至已註冊的號碼進行確認 |
| SWK | 擁有 | 軟體安全金鑰是否存在證明 |
| 電話 | 擁有 | 透過電話確認 |
| VBM | 固有 | 使用聲紋進行生物特徵辨識 |
如果找不到任何權杖問題,則 Microsoft Entra ID 會視為滿足 MFA,並將權杖發行給終端使用者。 否則,終端使用者的要求會失敗。
失敗會以發出錯誤回應參數來表示。
| 參數 | 值 | 說明 |
|---|---|---|
| 錯誤 | ASCII 錯誤碼,例如 access_denied 或 temporarily_unavailable。 |
如果回應中存在 id_token 參數,且權杖有效,則 Microsoft Entra ID 會視為要求成功。 否則,要求會被視為失敗。 由於條件式存取原則的需求,導致 Microsoft Entra ID 原始驗證嘗試失敗。
Microsoft Entra ID 會在將用戶重新導向至提供者後大約 5 分鐘,捨棄其端的驗證嘗試狀態。
Microsoft Entra ID 錯誤回應處理
Microsoft Azure 服務會使用 correlationId,將各種內部和外部系統的呼叫相互關聯。 它可用作整個作業或流程的通用識別碼,這些識別碼可能牽涉到多個 HTTP 呼叫。 在任何作業期間發生錯誤時,回應會包含名為相互關聯識別碼的欄位。
當您連絡 Microsoft支援服務或類似的服務時,請提供此相互關聯識別碼的值,因為它有助於更快速地存取遙測和記錄。
例如:
ENTRA IDSTS70002︰驗證認證時發生錯誤。 ENTRA IDSTS50012:來自簽發者 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' 的外部 ID 標記未能通過簽章驗證。 Token 的 KeyID 是 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' 追蹤標識符:0000aaaa-11bb-cccc-dd22-eeeeee33333 相互關聯標識符:aaaa0000-bb11-2222-33cc-444444ddddddd 時間戳:2023-07-24 16:51:34Z
自訂控制項和企業資產管理
在 Microsoft Entra ID 中,EAM 和條件式存取自訂控制項可以在客戶準備並移轉至 EAM 時平行運作。
目前使用自訂控制項與外部提供者整合的客戶可以繼續使用它們,以及他們設定用來管理存取的任何條件式存取原則。 建議系統管理員在移轉期間建立一組平行的條件式存取原則:
政策應該使用需要多重要素驗證的授權控制,而不是自訂控制。
注意
EAM 無法滿足於根據驗證強度來授與控制項,包括內建 MFA 強度。 原則應該只使用 [需要多重要素驗證] 來設定。 稍後將會支援具有驗證強度的 EAM。
新的原則可以先使用使用者子集進行測試。 測試群組會從需要自訂控制項的原則中排除,並包含在需要 MFA 的原則中。 一旦系統管理員確定由 EAM 滿足需要 MFA 的原則之後,系統管理員可以在原則中包含所有必要的使用者,並授予 MFA 驗證,針對自定義控件所設定的原則可以移至 關閉。
整合支援
如果您在建置 EAM 與 Microsoft Entra ID 整合時發生任何問題,Microsoft 客戶體驗工程 (CxE) 獨立解決方案廠商 (ISV) 或許可以提供協助。 若要與 CxE ISV 小組互動,請提交 協助要求。
參考資料
詞彙
| 術語 | 說明 |
|---|---|
| MFA | 多重要素驗證。 |
| 企業資產管理 (EAM) | 外部驗證方法是來自 Microsoft Entra ID 以外提供者的驗證方法,用作驗證使用者的一部分。 |
| OIDC | Open ID Connect 是以 OAuth 2.0 為基礎的驗證通訊協定。 |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | 一個用於外部驗證方法整合的應用程式ID範例。 |
下一步
如需如何在 Microsoft Entra 系統管理中心設定 EAM 的詳細資訊,請參閱 在 Microsoft (Preview) 中管理外部驗證方法。