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 autentiseringsprovider kan integreras med Microsoft Entra ID-klienter 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 (inherence)
EAM:er implementeras ovanpå Open ID Connect (OIDC). Den här implementeringen kräver minst tre offentligt riktade 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 autentiseringsprovidern 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 ett program för flera klientorganisationer. Privilegierade rolladministratörer måste bevilja medgivande för att aktivera integreringen för sin klientorganisation.
Ett program med flera klienter minskar risken för felkonfiguration i varje klientorganisation. 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-klientorganisation om de inte har någon ännu.
Registrera ett program i klientorganisationen.
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 omfång i det här programmet.
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.
| Property | 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. |
| Program-ID:t | Providern kan använda program-ID:t som ClientId för sitt program. |
| Webbadress till startsida | Providerns startsides-URL används inte för något, men krävs som en del av programregistreringen. |
| Svars-URL | Giltiga omdirigerings-URL:er för providern. Man bör matcha providerns värd-URL som har angetts för providerns klientorganisation. 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 programmet krävs i klientorganisationen 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 provider kan konfigurera fler anspråk med hjälp av valfria anspråk för id_token.
Kommentar
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 extern identitetsprovider lagras i principen Autentiseringsmetoder för varje klientorganisation. Providerinformationen lagras som en autentiseringsmetod av typen externalAuthenticationMethodConfiguration.
Varje provider har en post i listobjektet för principen. 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 nästa avsnitt beskrivs providerkrav och innehåller exempel på interaktion med Microsoft Entra-ID med en provider.
Identifiering av providermetadata
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 .välkänd oidc-configuration, måste ingå i identifierings-URL/:en som konfigurerades när EAM skapas.
Slutpunkten returnerar ett JSON-dokument för providermetadata som finns där. Slutpunkten måste också returnera det giltiga innehållslängdshuvudet.
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 identifiering och iss-anspråket i de token som utfärdats av providerns 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. |
|
| scopes_supported | openid | Andra värden kan också inkluderas men krävs inte. |
| response_types_supported | id_token | Andra värden kan också inkluderas men krävs inte. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft har stöd för RS256 | |
| claim_types_supported | 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="
]
}
]
}
Kommentar
JWK x5c-parametern måste finnas för att tillhandahålla X.509-representationer av de nycklar som tillhandahålls.
Cachelagring av providermetadata
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 provider återställer sina nycklar:
- Publicera det befintliga certifikatet och 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 nyckelåterställning. Den beroende tjänsten måste vara beredd att hantera både omedelbara och periodiska 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. Mer information finns i Rollover för 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.
Microsoft Entra ID-metadataidentifieringsslutpunkter:
- 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 konsumenter av våra identifieringsmetadata.
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 har slutförts kan du arbeta med anspråksnyttolasten för att få information 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.
Kommentar
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. |
| response_mode | form_post | 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. | |
| redirect_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 den skickas in bör providern 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. | |
| anspråk | 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 for US Government:
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"]
}
}
}
Standardanspråk 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 app bör använda GUID-delen av anspråket för att begränsa den uppsättning klienter som kan logga in på appen, om 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 den här token inte är avsedd för autentisering finns det ingen anledning för dess giltighet att överleva begäran med mycket. | |
| iat | Ange utfärdandetid som vanligt. | |
| tid | Klientorganisations-ID:t är till för att annonsera klientorganisationen till providern. 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. | |
| preferred_username | 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. Det huvudnamn som token anger information om, till exempel användaren av ett program. 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. Ämnet är dock en parvis identifierare. det är unikt för ett visst 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 den används för något annat än ett tips utfärdas token som förfallen. 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å providersidan med kontot i Azure AD med hjälp av oid- och tid-anspråken. Dessa två anspråk är garanterat 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 har publicerats i Microsoft Entra-ID-anropet 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. Mer information om anspråken som anges i id_token_hint finns i 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 som utfärdats av den externa identitetsprovidern. | |
| 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 providerns identifieringsmetadata. | |
| 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 från id_token_hint skickas för att initiera denna begäran. | |
| nonce | Samma nonce som skickades i begäran. | |
| acr | Acr-anspråken 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-anspråken för den autentiseringsmetod som används vid autentisering. Det här värdet ska returneras som en matris och endast ett metodanspråk ska returneras. Listan över anspråk finns i Amr-anspråk som stöds. |
ACR-anspråk som stöds
| Anspråk | Kommentar |
|---|---|
| possessionorinherence | Autentiseringen måste ske med en innehavs- eller inherencebaserad faktor. |
| knowledgeorpossession | Autentisering måste ske med en kunskaps- eller innehavsbaserad faktor. |
| knowledgeorinherence | Autentisering måste ske med en kunskaps- eller inherence-baserad faktor. |
| knowledgeorpossessionorinherence | Autentiseringen måste ske med en kunskaps- eller innehavs- eller inherencebaserad faktor. |
| kunskap | Autentisering måste ske med kunskapsbas d-faktor. |
| besittning | Autentisering måste ske med innehavsbaserad faktor. |
| inherence | Autentisering måste ske med inherence-baserad faktor. |
Amr-anspråk som stöds
| Anspråk | Kommentar |
|---|---|
| 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 är uppfyllt för att utfärda en token med MFA-anspråk. 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 inherence.
Microsoft Entra ID verifierar typmappningen baserat på följande tabell.
| Anspråksmetod | Type | Anteckningar |
|---|---|---|
| ansikte | Inherence | Biometrisk med ansiktsigenkänning |
| Fido | Besittning | FIDO2 användes. Vissa implementeringar kan också kräva biometrisk, men typ av innehavsmetod mappas eftersom det är det primära säkerhetsattributet. |
| fpt | Inherence | Biometrisk med fingeravtryck |
| hwk | Besittning | Bevis på innehav av maskinvarusäkrad nyckel |
| iris | Inherence | Biometrisk med irisgenomsökning |
| otp | Besittning | Engångslösenord |
| Pop | Besittning | Bevis på innehav |
| retina | Inherence | 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 | Inherence | 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 misslyckadeshttps://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa signaturverifiering. KeyID för token är "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u" Trace ID: 0000aaaaa-11bb-cccc-dd22-eeeeee333333 Korrelations-ID: aaaa0000-bb11-2222-33cc-444444ddd 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.
Kommentar
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
| Period | 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).