Microsoft Entra-referens för multifaktorautentisering för extern metodprovider (förhandsversion)
Det här avsnittet beskriver hur en extern autentiseringsprovider ansluter till Microsoft Entra multifaktorautentisering (MFA). En extern autentiseringstjänstleverantör kan integreras med Microsoft Entra ID-hyresgäster som en extern autentiseringsmetod (EAM). En EAM kan uppfylla den andra faktorn i ett MFA-krav för åtkomst till en resurs eller ett program. EAM kräver minst en Microsoft Entra ID P1-licens.
När en användare loggar in utvärderas klientprinciperna. Autentiseringskraven bestäms baserat på den resurs som användaren försöker komma åt.
Flera principer kan gälla för inloggningen, beroende på deras parametrar. Dessa parametrar omfattar användare och grupper, program, plattform, risknivå för inloggning med mera.
Baserat på autentiseringskraven kan användaren behöva logga in med en annan faktor för att uppfylla MFA-kravet. Den andra faktorn måste komplettera typen av första faktor.
EAM:er läggs till i Microsoft Entra-ID av klientadministratören. Om en klientorganisation kräver en EAM för MFA anses inloggningen uppfylla MFA-kravet efter att Microsoft Entra-ID har verifierat båda:
- Den första faktorn slutfördes med Microsoft Entra-ID
- Den andra faktorn slutfördes med EAM
Valideringen uppfyller MFA-kravet för två eller flera typer av metoder från:
- Något du vet (kunskap)
- Något du har (innehav)
- Något du är (inneboende egenskap)
EAM:er implementeras ovanpå Open ID Connect (OIDC). Den här implementeringen kräver minst tre publikt tillgängliga slutpunkter.
- En OIDC Discovery-slutpunkt enligt beskrivningen i Identifiering av providermetadata
- En giltig OIDC-autentiseringsslutpunkt
- En URL där leverantörens offentliga certifikat publiceras
Nu ska vi titta närmare på hur inloggning fungerar med en EAM:
- En användare försöker logga in med en första faktor, till exempel ett lösenord, till ett program som skyddas av Microsoft Entra-ID.
- Microsoft Entra-ID avgör att en annan faktor måste uppfyllas. En princip för villkorsstyrd åtkomst kräver till exempel MFA.
- Användaren väljer EAM som en andra faktor.
- Microsoft Entra-ID omdirigerar användarens webbläsarsession till EAM-URL:en:
- Den här URL:en identifieras från identifierings-URL:en som etablerades av en administratör när de skapade EAM.
- Programmet tillhandahåller en token som har upphört att gälla eller nästan har upphört att gälla och som innehåller information för att identifiera användaren och klientorganisationen.
- Den externa autentiseringsprovidern verifierar att token kom från Microsoft Entra-ID och kontrollerar innehållet i token.
- Den externa autentiseringsprovidern kan också göra ett anrop till Microsoft Graph för att hämta ytterligare information om användaren.
- Den externa autentiseringsprovidern utför alla åtgärder som den anser vara nödvändiga, till exempel att autentisera användaren med vissa autentiseringsuppgifter.
- Den externa autentiseringsleverantören omdirigerar användaren tillbaka till Microsoft Entra ID med en giltig token, inklusive alla nödvändiga anspråk.
- Microsoft Entra-ID verifierar att tokens signatur kom från den konfigurerade externa autentiseringsprovidern och kontrollerar sedan innehållet i token.
- Microsoft Entra-ID verifierar token mot kraven.
- Användaren uppfyllde MFA-kravet om valideringen lyckas. Användaren kan också behöva uppfylla andra principkrav.
Konfigurera en ny extern autentiseringsprovider med Microsoft Entra-ID
Ett program som representerar integreringen krävs för att EAM ska kunna utfärda id_token_hint. Programmet kan skapas på två sätt:
- Skapas i varje klientorganisation som använder den externa providern.
- Skapades som en applikation för flera hyresgäster. Privilegierade rolladministratörer måste bevilja medgivande för att aktivera integreringen för sin klientorganisation.
En multitenant-applikation minskar risken för felkonfiguration i varje klient. Det gör också att leverantörer kan göra ändringar i metadata som svars-URL:er på ett ställe, i stället för att kräva att varje klientorganisation gör ändringarna.
För att konfigurera ett program med flera klientorganisationer måste provideradministratören först:
Skapa en Microsoft Entra ID-klient om de inte har någon ännu.
Registrera en applikation i deras klient.
Ange vilka kontotyper som stöds för programmet till: Konton i valfri organisationskatalog (Alla Microsoft Entra-ID-klientorganisationer – Multitenant).
Lägg till den delegerade behörigheten
openidochprofileför Microsoft Graph i programmet.Publicera inga behörigheter i den här applikationen.
Lägg till den externa identitetsproviderns giltiga authorization_endpoint URL:er i programmet som svars-URL:er.
Kommentar
Den authorization_endpoint som anges i providerns identifieringsdokument bör läggas till som en omdirigerings-URL i programregistreringen. Annars får du följande fel: ENTRA IDSTS50161: Det gick inte att verifiera auktoriserings-URL:en för den externa anspråksprovidern!
Programregistreringsprocessen skapar ett program med flera egenskaper. Dessa egenskaper krävs för vårt scenario.
| Egendom | beskrivning |
|---|---|
| Objekt-ID | Providern kan använda objekt-ID:t med Microsoft Graph för att fråga programinformationen. Providern kan använda objekt-ID:t för att programmatiskt hämta och redigera programinformationen. |
| Applikations-ID | Providern kan använda program-ID:t som ClientId för sitt program. |
| Webbadress till startsida | Startsides-URL:en för leverantören används inte för något, men krävs som en del av ansökningsregistreringen. |
| Svars-URL | Giltiga omdirigerings-URL:er för providern. Man bör matcha leverantörens värd-URL som har angetts för leverantörens klient. En av de registrerade svars-URL:erna måste matcha prefixet för den authorization_endpoint som Microsoft Entra-ID hämtar via OIDC-identifiering för värd-URL:en. |
Ett program för varje klientorganisation är också en giltig modell som stöder integreringen. Om du använder en registrering med en enda klientorganisation måste klientadministratören skapa en programregistrering med egenskaperna i föregående tabell för ett program med en enda klientorganisation.
Kommentar
Administratörsmedgivande för applikationen krävs i den klientorganisation som använder EAM. Om medgivande inte beviljas visas följande fel när en administratör försöker använda EAM: AADSTS900491: Tjänstens huvudnamn <ditt app-ID> hittades inte.
Konfigurera valfria anspråk
En leverantör kan konfigurera fler anspråk med hjälp av valfria anspråk för id_token.
Anmärkning
Oavsett hur programmet skapas måste providern konfigurera valfria anspråk för varje molnmiljö. Om ett program med flera klientorganisationer används för globala Azure och Azure for US Government kräver varje molnmiljö ett annat program- och program-ID.
Lägga till en EAM i Microsoft Entra-ID
Information om externa identitetsleverantörer lagras i policyn Autentiseringsmetoder för varje klientorganisation. Providerinformationen lagras som en autentiseringsmetod av typen externalAuthenticationMethodConfiguration.
Varje leverantör har en post i listobjektet för policyn. Varje post måste ange:
- Om metoden är aktiverad
- De inkluderade grupper som kan använda metoden
- De exkluderade grupper som inte kan använda metoden
Administratörer för villkorsstyrd åtkomst kan skapa en princip med Kräv MFA-beviljande för att ange MFA-kravet för användarinloggning. Externa autentiseringsmetoder stöds för närvarande inte med autentiseringsstyrkor.
Mer information om hur du lägger till en extern autentiseringsmetod i administrationscentret för Microsoft Entra finns i Hantera en extern autentiseringsmetod i Microsoft Entra-ID (förhandsversion).
Microsoft Entra ID-interaktion med providern
I de följande avsnitten förklaras leverantörskrav och det ges exempel på hur Microsoft Entra ID interagerar med en leverantör.
Upptäckt av leverantörsmetadata
En extern identitetsprovider måste tillhandahålla en OIDC Discovery-slutpunkt. Den här slutpunkten används för att hämta mer konfigurationsdata. Den fullständiga URL:en, inklusive .well-known/oidc-configuration, måste ingå i Discovery-URL:en som konfigureras när EAM skapas.
Slutpunkten returnerar ett JSON-dokument för providermetadata som finns där. Endpointen måste också returnera den giltiga content-length-rubriken.
I följande tabell visas de data som ska finnas i providerns metadata. Dessa värden krävs för det här utökningsscenariot. JSON-metadatadokumentet kan innehålla mer information.
För OIDC-dokumentet med värdena för Providermetadata, se Providermetadata.
| Metadatavärde | Värde | Kommentarer |
|---|---|---|
| Utfärdare | Den här URL:en ska matcha både värd-URL:en som används för upptäckt och iss-påståendet i de tokens som utfärdas av leverantörens tjänst. | |
| authorization_endpoint | Slutpunkten som Microsoft Entra-ID kommunicerar med för auktorisering. Den här slutpunkten måste finnas som en av svars-URL:erna för de tillåtna programmen. | |
| jwks_uri | Där Microsoft Entra ID kan hitta de offentliga nycklar som behövs för att verifiera de signaturer som utfärdats av providern. [!OBS!] JSON-webbnyckeln (JWK) x5c-parametern måste finnas för att tillhandahålla X.509-representationer av de nycklar som tillhandahålls. |
|
| Stödda områden | openid | Andra värden kan också inkluderas men krävs inte. |
| stödda svarsformat | id_token | Andra värden kan också inkluderas men krävs inte. |
| ämnestyper_som_stöds | ||
| id_token_signing_alg_values_supported | Microsoft har stöd för RS256 | |
| typer_av_anspråk_som_stöds | normal | Den här egenskapen är valfri, men om den finns bör den innehålla normalvärdet. andra värden kan också inkluderas. |
http://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",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
Anteckning
JWK x5c-parametern måste finnas för att tillhandahålla X.509-representationer av de nycklar som tillhandahålls.
Cachelagring av leverantörsmetadata
För att förbättra prestanda cachelagrar Microsoft Entra ID metadata som returneras av providern, inklusive nycklarna. Cachelagring av providermetadata förhindrar ett identifieringsanrop varje gång Microsoft Entra ID pratar med en extern identitetsprovider.
Den här cachen uppdateras var 24:e timme (en dag). Så här föreslår vi att en leverantör roterar sina kryptonycklar:
- Publicera det befintliga certifikatetoch det nya certifikatet i "jwks_uri".
- Fortsätt att signera med befintligt certifikat tills Microsoft Entra ID-cachen har uppdaterats, upphört att gälla eller uppdaterats (var 2:e dag).
- Växla till signering med nytt certifikat.
Vi publicerar inte scheman för nyckelväxlingar. Den beroende tjänsten måste vara beredd att hantera både omedelbara och periodiska övergångar (rollovers). Vi föreslår att du använder ett dedikerat bibliotek som skapats för detta ändamål, till exempel azure-activedirectory-identitymodel-extensions-for-dotnet. För mer information, se Genomgång av signeringsnyckel i Microsoft Entra-ID.
Identifiering av Microsoft Entra ID-metadata
Leverantörer måste också hämta de offentliga nycklarna för Microsoft Entra-ID för att verifiera token som utfärdats av Microsoft Entra-ID.
Identifieringsslutpunkter för Microsoft Entra ID-metadata:
- Global Azure:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure for US Government:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure drivs av 21Vianet:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
Med hjälp av den offentliga nyckelidentifieraren från token ("kid" från JSON Web Signature (JWS)) kan man avgöra vilka av nycklarna som hämtas från egenskapen jwks_uri ska användas för att verifiera signaturen för Microsoft Entra-ID-token.
Validera token som utfärdats av Microsoft Entra ID
Information om hur du verifierar token som utfärdats av Microsoft Entra-ID finns i Validera och ID-token. Det finns inga särskilda steg för de konsumenterna av vår upptäcktsmetadata.
Microsofts tokenverifieringsbibliotek innehåller all information om detaljerna för tokenvalidering som dokumenteras, eller så kan de fastställas genom att bläddra i källkoden. Ett exempel finns i Azure-exempel.
När valideringen lyckas kan du arbeta med informationen om anspråk för att få detaljer om användaren och deras klientorganisation.
Kommentar
Det är viktigt att verifiera id_token_hint för att säkerställa att id_token_hint kommer från en Microsoft-klientorganisation och representerar din integrering. Id_token_hint bör verifieras fullt ut, särskilt signaturen, utfärdaren, målgruppen och de andra anspråksvärdena.
Microsoft Entra-ID-anrop till den externa identitetsprovidern
Microsoft Entra ID använder det implicita OIDC-flödet för att kommunicera med den externa identitetsprovidern. Med det här flödet sker kommunikationen med providern uteslutande med hjälp av providerns auktoriseringsslutpunkt. Microsoft Entra-ID skickar en token via parametern id_token_hint för att informera leverantören om den användare för vilken Microsoft Entra-ID:t gör begäran.
Det här anropet görs via en POST-begäran eftersom listan över parametrar som skickas till providern är stor. En stor lista förhindrar användning av webbläsare som begränsar längden på en GET-begäran.
Parametrarna för autentiseringsbegäran visas i följande tabell.
Anteckning
Om de inte visas i följande tabell bör andra parametrar i begäran ignoreras av providern.
| Frågeparameter för autentisering | Värde | beskrivning |
|---|---|---|
| omfattning | openid | |
| response_type | id-token | Värdet som används för det implicita flödet. |
| svarsläge | formulärinlägg | Vi använder postformuläret för att undvika problem med stora URL:er. Vi förväntar oss att alla parametrar skickas i brödtexten i begäran. |
| client_id | Klient-ID som ges till Microsoft Entra-ID av den externa identitetsprovidern, till exempel ABCD. Mer information finns i Beskrivning av extern autentiseringsmetod. | |
| omdirigerings-url | Den omdirigerings-URI (Uniform Resource Identifier) som den externa identitetsprovidern skickar svaret till (id_token_hint). | |
| Se ett exempel efter den här tabellen. | ||
| nonce | En slumpmässig sträng som genereras av Microsoft Entra-ID. Det kan vara sessions-ID:t. Om det tillhandahålls måste det returneras i svaret tillbaka till Microsoft Entra-ID. | |
| tillstånd | Om det skickas in bör leverantören returnera tillståndet i sitt svar. Microsoft Entra-ID använder tillstånd för att behålla kontexten för samtalet. | |
| id_token_hint | En token som utfärdats av Microsoft Entra-ID för slutanvändaren och skickats till förmån för providern. | |
| krav | En JSON-blob som innehåller de begärda anspråken. Mer information om formatet för den här parametern finns i parametern för anspråksbegäran från OIDC-dokumentationen och ett exempel efter den här tabellen. | |
| client-request-id | Ett GUID-värde | En provider kan logga det här värdet för att felsöka problem. |
Exempel på en omdirigerings-URI
Omdirigerings-URI:er (Uniform Resource Identifiers) bör registreras med providern utanför bandet. De omdirigerings-URI:er som kan skickas är:
- Global Azure:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure för den amerikanska regeringen:
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure drivs av 21Vianet:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Exempel på en EAM som uppfyller MFA
Här är ett exempel på en autentisering där en EAM uppfyller MFA. Det här exemplet hjälper en leverantör att veta vilka anspråk Microsoft Entra-ID förväntar sig.
Kombinationen av acr värdena och amr används av Microsoft Entra-ID:t för att verifiera:
- Autentiseringsmetoden som används för den andra faktorn uppfyller MFA-kravet
- Autentiseringsmetoden skiljer sig i "typ" från den metod som används för att slutföra den första faktorn för inloggning till 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"]
}
}
}
Standardpåståenden för Id_token_hint
I det här avsnittet beskrivs det nödvändiga innehållet i den token som skickas som id_token_hint i begäran till providern. Token kan innehålla fler anspråk än i följande tabell.
| Anspråk | Värde | beskrivning |
|---|---|---|
| iss | Identifierar säkerhetstokentjänsten (STS) som konstruerar och returnerar token och Microsoft Entra ID-klientorganisationen där användaren autentiserades. Din applikation bör använda GUID-delen av anspråket för att begränsa den uppsättning hyresgäster som kan logga in på applikationen, om det är tillämpligt. Utfärdaren bör matcha utfärdarens URL från JSON-metadata för OIDC-identifiering för klientorganisationen där användaren loggade in. | |
| Aud | Målgruppen ska anges till den externa identitetsproviderns klient-ID för Microsoft Entra-ID. | |
| exp | Förfallotiden är inställd på att upphöra en kort tid efter utfärdandetiden, tillräckligt för att undvika problem med tidsförskjutning. Eftersom denna token inte är avsedd för autentisering finns det ingen anledning för att den ska vara giltig längre än nödvändigt efter begäran. | |
| iat | Ange utfärdandetid som vanligt. | |
| tid | Hyresgäst-ID:t är till för att annonsera hyresgästen till leverantören. Den representerar den Microsoft Entra-ID-klientorganisation som användaren kommer från. | |
| Oid | Den oföränderliga identifieraren för ett objekt i Microsofts identitetsplattform. I det här fallet är det ett användarkonto. Den kan också användas för att utföra auktoriseringskontroller på ett säkert sätt och som en nyckel i databastabeller. Det här ID:t identifierar användaren unikt i olika program. Två olika program som loggar in samma användare får samma värde i oid-anspråket. Därför kan oid användas i frågor till Microsoft onlinetjänster, till exempel Microsoft Graph. | |
| önskat_användarnamn | Innehåller ett läsbart värde som identifierar subjektet för token. Det här värdet är inte garanterat unikt i en klientorganisation och är endast avsett för visningsändamål. | |
| under | Ämnesidentifierare för slutanvändaren på utfärdaren. Den huvudpart som token anger information om, till exempel användaren av en applikation. Det här värdet är oföränderligt och kan inte omtilldelas eller återanvändas. Den kan användas för att utföra auktoriseringskontroller på ett säkert sätt, till exempel när token används för att komma åt en resurs och kan användas som en nyckel i databastabeller. Eftersom ämnet alltid finns i de token som Microsoft Entra ID utfärdar rekommenderar vi att du använder det här värdet i ett allmänt auktoriseringssystem. Den identifierare som avses är dock en parvis kopplad identifierare och är unik för ett specifikt program-ID. Om en enskild användare loggar in på två olika program med två olika klient-ID:er får dessa program därför två olika värden för ämnesanspråket. Det här resultatet kan vara önskat eller inte, beroende på din arkitektur och sekretesskrav. Se även oid-anspråket (som förblir detsamma mellan appar i en klientorganisation). |
För att förhindra att det används för något annat än en ledtråd ges token ut som ett utgånget. Token är signerad och kan verifieras med hjälp av publicerade Microsoft Entra ID-identifieringsmetadata.
Valfria anspråk från Microsoft Entra-ID
Om en provider behöver valfria anspråk från Microsoft Entra-ID kan du konfigurera följande valfria anspråk för id_token: given_name, family_name, preferred_username, upn. Mer information finns i Valfria anspråk.
Rekommenderad användning av anspråk
Microsoft rekommenderar att du associerar konton på leverantörens sida med kontot i Azure AD genom att använda oid- och tid-kraven. Dessa två påståenden är säkerställda som unika för kontot i klientorganisationen.
Exempel på en id_token_hint
Här är ett exempel på en id_token_hint för en katalogmedlem:
{
"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"
}.
Här är ett exempel på id_token tips för en gästanvändare i klientorganisationen:
{
"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"
}.
Föreslagna åtgärder för externa identitetsprovidrar
Vi föreslår att externa identitetsprovidrar slutför de här stegen. Listan är inte fullständig och leverantörer bör utföra andra valideringssteg som de anser lämpligt.
- Från begäran:
- Kontrollera att redirect_uri är publicerad i Microsoft Entra ID-anrop till den externa identitetsprovidern.
- Kontrollera att client_id har ett värde tilldelat till Microsoft Entra-ID, till exempel ABCD.
- Providern bör först verifiera id_token_hint som visas för den av Microsoft Entra-ID:t.
- Från anspråken i id_token_hint:
- De kan också ringa ett anrop till Microsoft Graph för att hämta annan information om den här användaren. oid- och tid-anspråken i id_token_hint är användbara i detta avseende. För information om anspråken som tillhandahålls i id_token_hint, se Standard id_token_hint-anspråk.
- Utför sedan andra autentiseringsaktiviteter som leverantörens produkt är byggd för.
- Beroende på resultatet av användarens åtgärder och andra faktorer skulle providern sedan konstruera och skicka ett svar tillbaka till Microsoft Entra-ID, enligt beskrivningen i nästa avsnitt.
Microsoft Entra-ID-bearbetning av providersvaret
Providern måste skicka ett svar tillbaka till redirect_uri. Följande parametrar bör anges för ett lyckat svar:
| Parameter | Värde | beskrivning |
|---|---|---|
| id_token | Token utfärdat av den externa identitetsleverantören. | |
| tillstånd | Samma tillstånd som skickades i begäran, om det finns något. Annars bör det här värdet inte finnas. |
Vid lyckat resultat skulle providern sedan utfärda en id_token för användaren. Microsoft Entra ID använder publicerade OIDC-metadata för att verifiera att token innehåller de förväntade anspråken och utför all annan validering av token som OIDC kräver.
| Anspråk | Värde | beskrivning |
|---|---|---|
| iss | Utfärdare – måste matcha utfärdaren från leverantörens upptäcktsmetadata. | |
| Aud | Målgrupp – Microsoft Entra ID-klient-ID. Se client_id i Microsoft Entra ID-anrop till den externa identitetsprovidern. | |
| exp | Förfallotid – ange som vanligt. | |
| iat | Utfärdandetid – ange som vanligt. | |
| under | Ämne – måste matcha sub i id_token_hint som skickas för att initiera denna begäran. | |
| nonce | Samma nonce som skickades i begäran. | |
| acr | Acr-krav för autentiseringsbegäran. Det här värdet ska matcha ett av värdena från den begäran som skickas för att initiera den här begäran. Endast ett acr-anspråk ska returneras. Listan över anspråk finns i ACR-anspråk som stöds. | |
| Amr | Amr-påståendena för metoden som används vid autentisering. Det här värdet ska returneras som en matris och endast ett metodanspråk ska returneras. För listan över anspråk, se stödda AMR-anspråk. |
ACR-anspråk som stöds
| Anspråk | Anteckningar |
|---|---|
| besittning eller inneboende | Autentiseringen måste ske med en innehavs- eller inherencebaserad faktor. |
| kunskap eller innehav | Autentisering måste ske med en kunskaps- eller innehavsbaserad faktor. |
| knowledgeorinherence | Autentisering måste ske med en kunskaps- eller inherence-baserad faktor. |
| kunskaps-eller-besittnings-eller-inneboende | Autentiseringen måste ske med en kunskaps- eller innehavs- eller inherencebaserad faktor. |
| kunskap | Autentisering måste ske med kunskapsbaserad faktor. |
| besittning | Autentisering måste ske med innehavsbaserad faktor. |
| inneboende | Autentisering måste ske med inherence-baserad faktor. |
Amr-anspråk som stöds
| Anspråk | Anteckningar |
|---|---|
| ansikte | Biometrisk med ansiktsigenkänning |
| Fido | FIDO2 användes |
| fpt | Biometrisk med fingeravtryck |
| hwk | Bevis på innehav av maskinvarusäkrad nyckel |
| iris | Biometrisk med irisgenomsökning |
| otp | Engångslösenord |
| Pop | Bevis på innehav |
| retina | Biometrisk genomsökning av näthinna |
| Sc | Smartkort |
| sms | Bekräftelse via text till registrerat nummer |
| swk | Bekräftelse av förekomsten av en programvaruskyddad nyckel |
| Tel | Bekräftelse per telefon |
| vbm | Biometrisk med röstavtryck |
Microsoft Entra ID kräver att MFA ska vara uppfyllt för att utfärda en token med MFA-krav. Därför kan endast metoder med en annan typ uppfylla det andra faktorkravet. Som tidigare nämnts är de olika metodtyper som kan användas för att uppfylla den andra faktorn kunskap, innehav och inneboende egenskaper.
Microsoft Entra ID verifierar typmappningen baserat på följande tabell.
| Anspråksmetod | Typ | Anteckningar |
|---|---|---|
| ansikte | Inhäritens | Biometrisk med ansiktsigenkänning |
| Fido | Innehav | FIDO2 användes. Vissa implementeringar kan också kräva biometrisk, men typ av innehavsmetod mappas eftersom det är det primära säkerhetsattributet. |
| fpt | Medföddhet | Biometrisk med fingeravtryck |
| hwk | Besittning | Bevis på innehav av maskinvarusäkrad nyckel |
| iris | Inneboende egenskap | Biometrisk med irisgenomsökning |
| otp | Besittning | Engångslösenord |
| Pop | Besittning | Bevis på innehav |
| retina | Inhärens | Biometrisk genomsökning av näthinna |
| Sc | Besittning | Smartkort |
| sms | Besittning | Bekräftelse via text till registrerat nummer |
| swk | Besittning | Bevis på förekomsten av en programvaruskyddad nyckel |
| Tel | Besittning | Bekräftelse per telefon |
| vbm | Inhärense | Biometrisk med röstavtryck |
Om inga problem hittas med token anser Microsoft Entra ID att MFA är uppfyllt och utfärdar en token till slutanvändaren. Annars misslyckas slutanvändarens begäran.
Felet anges genom att felsvarsparametrar utfärdas.
| Parameter | Värde | beskrivning |
|---|---|---|
| Fel | En ASCII-felkod, till exempel access_denied eller temporarily_unavailable. |
Microsoft Entra ID anser att begäran lyckas om parametern id_token finns i svaret och om token är giltig. Annars anses begäran vara misslyckad. Microsoft Entra-ID:t misslyckas med det ursprungliga autentiseringsförsöket på grund av kravet på principen för villkorsstyrd åtkomst.
Microsoft Entra-ID överger tillståndet för autentiseringsförsöket i slutet cirka 5 minuter efter omdirigeringen till providern.
Hantering av Microsoft Entra-ID-felsvar
Microsoft Azure-tjänster använder ett correlationId för att korrelera anrop mellan olika interna och externa system. Det fungerar som en gemensam identifierare för hela åtgärden eller flödet som potentiellt omfattar flera HTTP-anrop. När ett fel inträffar under någon av åtgärderna innehåller svaret ett fält med namnet Korrelations-ID.
När du kontaktar Microsofts support eller en liknande tjänst anger du värdet för det här korrelations-ID:t eftersom det hjälper dig att komma åt telemetrin och loggarna snabbare.
Till exempel:
ENTRA IDSTS70002: Fel vid validering av autentiseringsuppgifter. ENTRA IDSTS50012: Extern ID-token från utfärdaren 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' kunde inte verifieras. KeyID för token är 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333 Korrelations-ID: aaaa0000-bb11-2222-33cc-444444dddddd Tidsstämpel: 2023-07-24 16:51:34Z
Anpassade kontroller och EAM:er
I Microsoft Entra-ID kan EAM:er och anpassade kontroller för villkorsstyrd åtkomst fungera parallellt medan kunderna förbereder sig för och migrerar till EAM:er.
Kunder som för närvarande använder en integrering med en extern provider med hjälp av anpassade kontroller kan fortsätta att använda dem och eventuella principer för villkorsstyrd åtkomst som de har konfigurerat för att hantera åtkomst. Administratörer rekommenderas att skapa en parallell uppsättning principer för villkorsstyrd åtkomst under migreringsperioden:
Principerna bör använda behörigheten Kräv beviljande av multifaktorautentisering i stället för beviljande av anpassad kontroll.
Anteckning
Bevilja kontroller baserat på autentiseringsstyrkor, inklusive den inbyggda MFA-styrkan, uppfylls inte av EAM. Principer bör endast konfigureras med Kräv multifaktorautentisering. Vi arbetar aktivt för att stödja EAM:er med autentiseringsstyrkor.
Den nya principen kan testas först med en delmängd användare. Testgruppen skulle undantas från principen som kräver anpassade kontroller och inkluderas i principen som kräver MFA. När administratören är säker på att principen som kräver MFA uppfylls av EAM kan administratören inkludera alla nödvändiga användare i principen med MFA-beviljandet, och principen som konfigurerats för anpassade kontroller kan flyttas till Av.
Integrationsstöd
Om du har problem när du skapar EAM-integrering med Microsoft Entra-ID kan den oberoende lösningsleverantören för Microsoft Customer Experience Engineering (CxE) (ISV) hjälpa till. Om du vill kontakta CxE ISV-teamet skickar du en begäran om hjälp.
Referenser
Ordlista
| Termin | beskrivning |
|---|---|
| Multifaktorautentisering | Multifaktorautentisering. |
| EAM | En extern autentiseringsmetod är en autentiseringsmetod från en annan provider än Microsoft Entra-ID som används som en del av autentiseringen av en användare. |
| OIDC | Open ID Connect är ett autentiseringsprotokoll baserat på OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | Ett exempel på ett appid integrerat för en extern autentiseringsmetod. |
Nästa steg
Mer information om hur du konfigurerar en EAM i administrationscentret för Microsoft Entra finns i Hantera en extern autentiseringsmetod i Microsoft (förhandsversion).