Referentie voor externe methodeprovider voor Microsoft Entra-verificatie met meerdere factoren (preview)
In dit onderwerp wordt beschreven hoe een externe verificatieprovider verbinding maakt met Microsoft Entra multifactor authentication (MFA). Een externe verificatieprovider kan worden geïntegreerd met Microsoft Entra ID-tenants als een externe verificatiemethode (EAM). Een EAM kan voldoen aan de tweede factor van een MFA-vereiste voor toegang tot een resource of toepassing. EAM's hebben ten minste een Licentie voor Microsoft Entra ID P1 nodig.
Wanneer een gebruiker zich aanmeldt, wordt dat tenantbeleid geëvalueerd. De verificatievereisten worden bepaald op basis van de resource waartoe de gebruiker toegang probeert te krijgen.
Er kunnen meerdere beleidsregels van toepassing zijn op de aanmelding, afhankelijk van hun parameters. Deze parameters omvatten gebruikers en groepen, toepassingen, platform, aanmeldingsrisiconiveau en meer.
Op basis van de verificatievereisten moet de gebruiker zich mogelijk aanmelden met een andere factor om te voldoen aan de MFA-vereiste. De tweede factor moet het type eerste factor aanvullen.
EAM's worden toegevoegd aan Microsoft Entra-id door de tenantbeheerder. Als voor een tenant een EAM voor MFA is vereist, wordt de aanmelding beschouwd als voldoen aan de MFA-vereiste nadat Microsoft Entra ID beide heeft gevalideerd:
- De eerste factor die is voltooid met Microsoft Entra-id
- De tweede factor voltooid met de EAM
Deze validatie voldoet aan de MFA-vereiste voor twee of meer typen methoden van:
- Iets wat u weet (kennis)
- Iets wat je hebt (bezit)
- Iets wat je bent (inherence)
EAM's worden geïmplementeerd boven op Open ID Connect (OIDC). Voor deze implementatie zijn ten minste drie openbaar gerichte eindpunten vereist:
- Een OIDC Discovery-eindpunt, zoals beschreven in detectie van metagegevens van providers
- Een geldig OIDC-verificatie-eindpunt
- Een URL waarin de openbare certificaten van de provider worden gepubliceerd
Laten we eens kijken hoe aanmelden werkt met een EAM:
- Een gebruiker probeert zich aan te melden met een eerste factor, zoals een wachtwoord, voor een toepassing die wordt beveiligd door Microsoft Entra-id.
- Microsoft Entra ID bepaalt dat aan een andere factor moet worden voldaan. Voor een beleid voor voorwaardelijke toegang is bijvoorbeeld MFA vereist.
- De gebruiker kiest de EAM als tweede factor.
- Microsoft Entra ID leidt de browsersessie van de gebruiker om naar de EAM-URL:
- Deze URL wordt gedetecteerd op basis van de detectie-URL die is ingericht door een beheerder bij het maken van de EAM.
- De toepassing biedt een verlopen of bijna verlopen token dat informatie bevat om de gebruiker en tenant te identificeren.
- De externe verificatieprovider valideert dat het token afkomstig is van Microsoft Entra-id en controleert de inhoud van het token.
- De externe verificatieprovider kan eventueel een aanroep naar Microsoft Graph doen om aanvullende informatie over de gebruiker op te halen.
- De externe verificatieprovider voert alle acties uit die nodig zijn, zoals het verifiëren van de gebruiker met een bepaalde referentie.
- De externe verificatieprovider leidt de gebruiker terug naar Microsoft Entra-id met een geldig token, inclusief alle vereiste claims.
- Microsoft Entra ID valideert dat de handtekening van het token afkomstig is van de geconfigureerde externe verificatieprovider en controleert vervolgens de inhoud van het token.
- Microsoft Entra ID valideert het token op basis van de vereisten.
- De gebruiker voldoet aan de MFA-vereiste als de validatie slaagt. De gebruiker moet mogelijk ook voldoen aan andere beleidsvereisten.
Een nieuwe externe verificatieprovider configureren met Microsoft Entra-id
Een toepassing die de integratie vertegenwoordigt, is vereist voor EAM's om de id_token_hint uit te geven. De toepassing kan op twee manieren worden gemaakt:
- Gemaakt in elke tenant die gebruikmaakt van de externe provider.
- Gemaakt als één multitenant-toepassing. Beheerders van bevoorrechte rollen moeten toestemming verlenen om de integratie voor hun tenant in te schakelen.
Een multitenant-toepassing vermindert de kans op onjuiste configuratie in elke tenant. Ook kunnen providers op één plaats wijzigingen aanbrengen in metagegevens, zoals antwoord-URL's, in plaats van dat elke tenant de wijzigingen moet aanbrengen.
Als u een multitenant-toepassing wilt configureren, moet de providerbeheerder eerst:
Maak een Microsoft Entra ID-tenant als ze er nog geen hebben.
Registreer een toepassing in hun tenant.
Stel de ondersteunde accounttypen van de toepassing in op: Accounts in elke organisatiemap (Elke Microsoft Entra ID-tenant - Multitenant).
Voeg de gedelegeerde machtiging
openidenprofilevan Microsoft Graph toe aan de toepassing.Publiceer geen bereiken in deze toepassing.
Voeg de geldige authorization_endpoint URL's van de externe id-provider toe aan die toepassing als antwoord-URL's.
Notitie
De authorization_endpoint in het detectiedocument van de provider moet worden toegevoegd als een omleidings-URL in de registratie van de toepassing. Anders krijgt u de volgende fout: ENTRA IDSTS50161: Kan autorisatie-URL van externe claimprovider niet valideren.
Het registratieproces van de toepassing maakt een toepassing met verschillende eigenschappen. Deze eigenschappen zijn vereist voor ons scenario.
| Eigenschappen | Beschrijving |
|---|---|
| Object-id | De provider kan de object-id met Microsoft Graph gebruiken om de toepassingsgegevens op te vragen. De provider kan de object-id gebruiken om de toepassingsgegevens programmatisch op te halen en te bewerken. |
| Toepassings-id | De provider kan de toepassings-id als client-id van de toepassing gebruiken. |
| URL van startpagina | De URL van de startpagina van de provider wordt niet gebruikt voor iets, maar is vereist als onderdeel van de registratie van de toepassing. |
| Antwoord-URL's | Geldige omleidings-URL's voor de provider. Een moet overeenkomen met de host-URL van de provider die is ingesteld voor de tenant van de provider. Een van de geregistreerde antwoord-URL's moet overeenkomen met het voorvoegsel van de authorization_endpoint die door Microsoft Entra-id worden opgehaald via OIDC-detectie voor de host-URL. |
Een toepassing voor elke tenant is ook een geldig model ter ondersteuning van de integratie. Als u een registratie met één tenant gebruikt, moet de tenantbeheerder een toepassingsregistratie maken met de eigenschappen in de voorgaande tabel voor een toepassing met één tenant.
Notitie
Beheerderstoestemming voor de toepassing is vereist in de tenant die gebruikmaakt van de EAM. Als er geen toestemming wordt verleend, wordt de volgende fout weergegeven wanneer een beheerder probeert de EAM te gebruiken: AADSTS900491: Service-principal <die uw app-id> niet heeft gevonden.
Optionele claims configureren
Een provider kan meer claims configureren met optionele claims voor id_token.
Notitie
Ongeacht hoe de toepassing wordt gemaakt, moet de provider optionele claims configureren voor elke cloudomgeving. Als een multitenant-toepassing wordt gebruikt voor globale Azure en Azure for US Government, vereist elke cloudomgeving een andere toepassing en toepassings-id.
Een EAM toevoegen aan Microsoft Entra-id
Externe id-providergegevens worden opgeslagen in het beleid voor verificatiemethoden van elke tenant. De providergegevens worden opgeslagen als verificatiemethode van het type externalAuthenticationMethodConfiguration.
Elke provider heeft één vermelding in het lijstobject van het beleid. Elke vermelding moet de volgende status hebben:
- Als de methode is ingeschakeld
- De opgenomen groepen die de methode kunnen gebruiken
- De uitgesloten groepen die de methode niet kunnen gebruiken
Beheerders van voorwaardelijke toegang kunnen een beleid maken met de MFA-toekenning vereisen om de MFA-vereiste voor aanmelding van gebruikers in te stellen. Externe verificatiemethoden worden momenteel niet ondersteund met verificatiesterkten.
Zie Een externe verificatiemethode beheren in Microsoft Entra ID (preview) voor meer informatie over het toevoegen van een externe verificatiemethode in het Microsoft Entra-beheercentrum.
Interactie met Microsoft Entra-id met provider
In de volgende secties worden providervereisten uitgelegd en worden voorbeelden opgenomen voor interactie met Microsoft Entra-id's met een provider.
Detectie van metagegevens van providers
Een externe id-provider moet een OIDC Discovery-eindpunt opgeven. Dit eindpunt wordt gebruikt om meer configuratiegegevens op te halen. De volledige URL, inclusief .bekende/oidc-configuratie moet worden opgenomen in de detectie-URL die is geconfigureerd wanneer de EAM wordt gemaakt.
Het eindpunt retourneert een JSON-document met metagegevens van provider dat daar wordt gehost. Het eindpunt moet ook de geldige header met inhoudslengte retourneren.
De volgende tabel bevat de gegevens die aanwezig moeten zijn in de metagegevens van de provider. Deze waarden zijn vereist voor dit uitbreidbaarheidsscenario. Het JSON-metagegevensdocument bevat mogelijk meer informatie.
Zie Metagegevens van provider voor het OIDC-document met de waarden voor metagegevens van provider.
| Metagegevenswaarde | Weergegeven als | Opmerkingen |
|---|---|---|
| Verlener | Deze URL moet overeenkomen met zowel de host-URL die wordt gebruikt voor detectie als de iss-claim in de tokens die zijn uitgegeven door de service van de provider. | |
| authorization_endpoint | Het eindpunt waarmee Microsoft Entra ID communiceert voor autorisatie. Dit eindpunt moet aanwezig zijn als een van de antwoord-URL's voor de toegestane toepassingen. | |
| jwks_uri | Waar Microsoft Entra ID de openbare sleutels kan vinden die nodig zijn om de handtekeningen te verifiëren die zijn uitgegeven door de provider. [!NOTE] De X5C-parameter (JSON Web Key) x5c moet aanwezig zijn om X.509-weergaven van opgegeven sleutels op te geven. |
|
| scopes_supported | openid | Andere waarden kunnen ook worden opgenomen, maar zijn niet vereist. |
| response_types_supported | id_token | Andere waarden kunnen ook worden opgenomen, maar zijn niet vereist. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft ondersteunt RS256 | |
| claim_types_supported | normaal | Deze eigenschap is optioneel, maar als deze aanwezig is, moet deze de normale waarde bevatten; andere waarden kunnen ook worden opgenomen. |
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": "CEYm9GmLvfIqrl0zBJc9-Chk_LM",
"x5t": "CEYm9GmLvfIqrl0zBJc9-Chk_LM",
"n": "jq277LRoE6WKM0awT3b-—redacted--vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jEzEd0nvztzAVM6Uy—redacted--Z0HBHjTZq9IWiPHSWo0rzA="
]
}
]
}
Notitie
De JWK x5c-parameter moet aanwezig zijn om X.509-weergaven van opgegeven sleutels op te geven.
Cacheopslag van providermetagegevens
Om de prestaties te verbeteren, slaat Microsoft Entra ID metagegevens op die door de provider worden geretourneerd, inclusief de sleutels. Het opslaan van metagegevens van providers voorkomt een detectieaanroep telkens wanneer Microsoft Entra ID met een externe id-provider praat.
Deze cache wordt elke 24 uur vernieuwd (één dag). U kunt als volgt voorstellen dat een provider de sleutels overdraait:
- Publiceer het bestaande certificaat en het nieuwe certificaat in de jwks_uri.
- Blijf ondertekenen met bestaand certificaat totdat de Microsoft Entra ID-cache wordt vernieuwd, verlopen of bijgewerkt (elke 2 dagen).
- Overschakelen naar ondertekening met Nieuw certificaat.
We publiceren geen planningen voor belangrijke rollovers. De afhankelijke service moet worden voorbereid om zowel onmiddellijke als periodieke rolliefhebbers te kunnen verwerken. We raden u aan een toegewezen bibliotheek te gebruiken die voor dit doel is gebouwd, zoals azure-activedirectory-identitymodel-extensions-for-dotnet. Zie Rollover voor ondertekeningssleutels in Microsoft Entra-id voor meer informatie.
Detectie van metagegevens van Microsoft Entra-id
Providers moeten ook de openbare sleutels van Microsoft Entra-id ophalen om de tokens te valideren die zijn uitgegeven door Microsoft Entra-id.
Detectie-eindpunten voor metagegevens van Microsoft Entra ID:
- Globale Azure:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure voor de Amerikaanse overheid:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure beheerd door 21Vianet:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
Met behulp van de openbare-sleutel-id van het token (de 'kid' van JSON Web Signature (JWS)) kan worden bepaald welke van de sleutels die zijn opgehaald uit de eigenschap jwks_uri moet worden gebruikt om de Microsoft Entra ID-tokenhandtekening te valideren.
Tokens valideren die zijn uitgegeven door Microsoft Entra-id
Zie Valideren en id-token voor informatie over het valideren van de tokens die zijn uitgegeven door Microsoft Entra ID-id. Er zijn geen speciale stappen voor de gebruikers van onze detectiemetagegevens.
De tokenvalidatiebibliotheek van Microsoft bevat alle details over de specifieke kenmerken van tokenvalidatie die worden gedocumenteerd, of ze kunnen worden vastgesteld door de broncode te doorzoeken. Zie Azure-voorbeelden voor een voorbeeld.
Zodra de validatie is voltooid, kunt u met de nettolading van claims werken om details van de gebruiker en hun tenant op te halen.
Notitie
Het is belangrijk om de id_token_hint te valideren om ervoor te zorgen dat de id_token_hint afkomstig is van een Microsoft-tenant en uw integratie vertegenwoordigt. De id_token_hint moet volledig worden gevalideerd, met name de handtekening, de uitgever, de doelgroep en de andere claimwaarden.
Microsoft Entra ID-aanroep naar de externe id-provider
Microsoft Entra ID maakt gebruik van de impliciete OIDC-stroom om te communiceren met de externe id-provider. Met deze stroom wordt communicatie met de provider uitsluitend uitgevoerd met behulp van het autorisatie-eindpunt van de provider. Als u de provider wilt laten weten voor wie Microsoft Entra ID de aanvraag doet, geeft Microsoft Entra-id een token door via de parameter id_token_hint .
Deze aanroep wordt gedaan via een POST-aanvraag omdat de lijst met parameters die aan de provider worden doorgegeven, groot is. Een grote lijst voorkomt het gebruik van browsers die de lengte van een GET-aanvraag beperken.
De parameters voor verificatieaanvragen worden vermeld in de volgende tabel.
Notitie
Tenzij ze worden vermeld in de volgende tabel, moeten andere parameters in de aanvraag worden genegeerd door de provider.
| Verificatiequeryparameter | Weergegeven als | Beschrijving |
|---|---|---|
| bereik | openid | |
| response_type | Id_token | De waarde die wordt gebruikt voor de impliciete stroom. |
| response_mode | form_post | We gebruiken formulier POST om problemen met grote URL's te voorkomen. We verwachten dat alle parameters worden verzonden in de hoofdtekst van de aanvraag. |
| client_id | De client-id die wordt gegeven aan Microsoft Entra-id door de externe id-provider, zoals ABCD. Zie de beschrijving van de externe verificatiemethode voor meer informatie. | |
| redirect_url | De omleidings-URI (Uniform Resource Identifier) waarnaar de externe id-provider het antwoord verzendt (id_token_hint). | |
| Bekijk een voorbeeld na deze tabel. | ||
| nonce | Een willekeurige tekenreeks die wordt gegenereerd door Microsoft Entra-id. Dit kan de sessie-id zijn. Indien opgegeven, moet deze worden geretourneerd in het antwoord op Microsoft Entra-id. | |
| staat | Als deze is doorgegeven, moet de provider de status retourneren in het antwoord. Microsoft Entra ID gebruikt de status om context over de aanroep te behouden. | |
| id_token_hint | Een token dat is uitgegeven door Microsoft Entra ID voor de eindgebruiker en doorgegeven voor het voordeel van de provider. | |
| claims | Een JSON-blob die de aangevraagde claims bevat. Zie de claimaanvraagparameter uit de OIDC-documentatie en een voorbeeld na deze tabel voor meer informatie over de indeling van deze parameter. | |
| client-request-id | Een GUID-waarde | Een provider kan deze waarde registreren om problemen op te lossen. |
Voorbeeld van een omleidings-URI
De omleidings-URI's (Uniform Resource Identifiers) moeten worden geregistreerd bij de externe provider. De omleidings-URI's die kunnen worden verzonden, zijn:
- Globale Azure:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure voor de Amerikaanse overheid:
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure beheerd door 21Vianet:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Voorbeeld van een EAM die voldoet aan MFA
Hier volgt een voorbeeld van een verificatie waarbij een EAM voldoet aan MFA. In dit voorbeeld kan een provider weten welke claims Microsoft Entra ID verwacht.
De combinatie van de waarden en amr waarden acr wordt gebruikt door Microsoft Entra ID om het volgende te valideren:
- De verificatiemethode die voor de tweede factor wordt gebruikt, voldoet aan de MFA-vereiste
- De verificatiemethode verschilt in 'type' van de methode die wordt gebruikt om de eerste factor voor aanmelding bij Microsoft Entra-id te voltooien
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
Standaardclaims voor Id_token_hint
In deze sectie wordt de vereiste inhoud van het token beschreven dat is doorgegeven als id_token_hint in de aanvraag die is ingediend bij de provider. Het token kan meer claims bevatten dan in de volgende tabel.
| Claim | Weergegeven als | Beschrijving |
|---|---|---|
| iss | Identificeert de beveiligingstokenservice (STS) die het token samenricht en retourneert, en de Microsoft Entra ID-tenant waarin de gebruiker is geverifieerd. Uw app moet het GUID-gedeelte van de claim gebruiken om de set tenants te beperken die zich kunnen aanmelden bij de app, indien van toepassing. De verlener moet overeenkomen met de URL van de uitgever uit de JSON-metagegevens van de OIDC-detectie voor de tenant waarin de gebruiker zich heeft aangemeld. | |
| aud | De doelgroep moet worden ingesteld op de client-id van de externe id-provider voor Microsoft Entra-id. | |
| exp | De verlooptijd is ingesteld op een korte tijd na de uitgiftetijd, voldoende om problemen met tijdverschil te voorkomen. Omdat dit token niet is bedoeld voor verificatie, is er geen reden voor de geldigheid om de aanvraag veel te kunnen uitstaan. | |
| iat | Stel de uitgiftetijd in zoals gebruikelijk. | |
| tid | De tenant-id is bedoeld voor het adverteren van de tenant naar de provider. Het vertegenwoordigt de Microsoft Entra ID-tenant waaruit de gebruiker afkomstig is. | |
| oid | De onveranderbare id voor een object in het Microsoft Identity Platform. In dit geval is het een gebruikersaccount. Het kan ook worden gebruikt om autorisatiecontroles veilig uit te voeren en als sleutel in databasetabellen. Deze id identificeert de gebruiker uniek in verschillende toepassingen. Twee verschillende toepassingen die zich aanmelden bij dezelfde gebruiker ontvangen dezelfde waarde in de oid-claim. Daarom kan oid worden gebruikt in query's voor Microsoft onlineservices, zoals Microsoft Graph. | |
| preferred_username | Biedt een voor mensen leesbare waarde waarmee het onderwerp van het token wordt geïdentificeerd. Deze waarde is niet gegarandeerd uniek binnen een tenant en is alleen bedoeld voor weergavedoeleinden. | |
| sub | Onderwerp-id voor de eindgebruiker bij de uitgever. De principal waarover het token informatie bevestigt, zoals de gebruiker van een toepassing. Deze waarde is onveranderbaar en kan niet opnieuw worden toegewezen of opnieuw worden gebruikt. Het kan worden gebruikt om autorisatiecontroles veilig uit te voeren, zoals wanneer het token wordt gebruikt voor toegang tot een resource en kan worden gebruikt als een sleutel in databasetabellen. Omdat het onderwerp altijd aanwezig is in de tokens die problemen ondervinden met Microsoft Entra ID, raden we u aan deze waarde te gebruiken in een autorisatiesysteem voor algemeen gebruik. Het onderwerp is echter een paargewijze id; het is uniek voor een bepaalde toepassings-id. Dus als één gebruiker zich aanmeldt bij twee verschillende toepassingen met twee verschillende client-id's, ontvangen deze toepassingen twee verschillende waarden voor de onderwerpclaim. Dit resultaat kan wel of niet gewenst zijn, afhankelijk van uw architectuur en privacyvereisten. Zie ook de oid-claim (die hetzelfde blijft tussen apps binnen een tenant). |
Om te voorkomen dat het wordt gebruikt voor iets anders dan een hint, wordt het token uitgegeven als verlopen. Het token is ondertekend en kan worden geverifieerd met behulp van de gepubliceerde microsoft Entra ID-detectiemetagegevens.
Optionele claims van Microsoft Entra-id
Als een provider optionele claims van Microsoft Entra ID nodig heeft, kunt u deze optionele claims configureren voor id_token. Zie Optionele claims voor meer informatie.
Aanbevolen gebruik van claims
Microsoft raadt u aan accounts aan de providerzijde te koppelen aan het account in Azure AD met behulp van de oid- en tid-claims. Deze twee claims zijn gegarandeerd uniek voor het account in de tenant.
Voorbeeld van een id_token_hint
Hier volgt een voorbeeld van een id_token_hint voor een directorylid:
{
"typ": "JWT",
"alg": "RS256",
"kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw"
}.{
"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"
}.
Hier volgt een voorbeeld van de id_token hint voor een gastgebruiker in de tenant:
{
"typ": "JWT",
"alg": "RS256",
"kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw"
}.{
"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"
}.
Voorgestelde acties voor externe id-providers
We raden u aan dat externe id-providers deze stappen uitvoeren. De lijst is niet volledig en providers moeten andere validatiestappen voltooien naar wens.
- Vanuit de aanvraag:
- Zorg ervoor dat de redirect_uri is gepubliceerd in de aanroep van Microsoft Entra ID naar de externe id-provider.
- Zorg ervoor dat de client_id een waarde heeft die is toegewezen aan Microsoft Entra-id, zoals ABCD.
- De provider moet eerst de id_token_hint valideren die aan de provider wordt gepresenteerd door Microsoft Entra-id.
- Uit de claims in de id_token_hint:
- Ze kunnen desgewenst microsoft Graph aanroepen om andere gegevens over deze gebruiker op te halen. De oid en tid claims in de id_token_hint zijn nuttig in dit verband. Zie Default id_token_hint claims voor meer informatie over de claims die zijn opgegeven in de id_token_hint.
- Voer vervolgens andere verificatieactiviteiten uit die door het product van de provider zijn gebouwd.
- Afhankelijk van het resultaat van de acties van de gebruiker en andere factoren, zou de provider vervolgens een antwoord maken en terugsturen naar Microsoft Entra-id, zoals wordt uitgelegd in de volgende sectie.
Microsoft Entra ID-verwerking van het antwoord van de provider
De provider moet een antwoord posten op de redirect_uri. De volgende parameters moeten worden opgegeven voor een geslaagd antwoord:
| Parameter | Weergegeven als | Beschrijving |
|---|---|---|
| id_token | Het token dat is uitgegeven door de externe id-provider. | |
| staat | Dezelfde status die is doorgegeven in de aanvraag, indien van toepassing. Anders mag deze waarde niet aanwezig zijn. |
Bij succes geeft de provider vervolgens een id_token uit voor de gebruiker. Microsoft Entra ID maakt gebruik van de gepubliceerde OIDC-metagegevens om te controleren of het token de verwachte claims bevat en voert een andere validatie uit van het token dat OIDC nodig heeft.
| Claim | Weergegeven als | Beschrijving |
|---|---|---|
| iss | Verlener: moet overeenkomen met de verlener van de detectiemetagegevens van de provider. | |
| aud | Doelgroep: de client-id van Microsoft Entra ID. Zie client_id in microsoft Entra ID-aanroep naar de externe id-provider. | |
| exp | Verlooptijd : ingesteld zoals gebruikelijk. | |
| iat | Uitgiftetijd– ingesteld zoals gebruikelijk. | |
| sub | Onderwerp: moet overeenkomen met het sub van het id_token_hint dat is verzonden om deze aanvraag te initiëren. | |
| nonce | Dezelfde nonce die is doorgegeven in de aanvraag. | |
| acr | De acr-claims voor de verificatieaanvraag. Deze waarde moet overeenkomen met een van de waarden uit de aanvraag die is verzonden om deze aanvraag te starten. Er moet slechts één acr-claim worden geretourneerd. Zie Ondersteunde acr-claims voor de lijst met claims. | |
| amr | De amrclaims voor de verificatiemethode die wordt gebruikt in verificatie. Deze waarde moet worden geretourneerd als een matrix en er moet slechts één methodeclaim worden geretourneerd. Zie Ondersteunde amr-claims voor de lijst met claims. |
Ondersteunde acr-claims
| Claim | Opmerkingen |
|---|---|
| bezitsbezit | Verificatie moet plaatsvinden met een op bezit of inherentie gebaseerde factor. |
| knowledgeorpossession | Verificatie moet plaatsvinden met een op kennis of bezit gebaseerde factor. |
| knowledgeorinherence | Verificatie moet plaatsvinden met een op kennis of inherentie gebaseerde factor. |
| knowledgeorpossessionorinherence | Verificatie moet plaatsvinden met een op kennis of bezit of inherentie gebaseerde factor. |
| knowledge | Verificatie moet plaatsvinden met kennisgebaseerde factor. |
| bezit | Verificatie moet plaatsvinden met een op bezit gebaseerde factor. |
| inherence | Verificatie moet plaatsvinden met een op inherence gebaseerde factor. |
Ondersteunde amrclaims
| Claim | Opmerkingen |
|---|---|
| face | Biometrie met gezichtsherkenning |
| Fido | FIDO2 is gebruikt |
| fpt | Biometrie met vingerafdruk |
| hwk | Bewijs van het bezit van met hardware beveiligde sleutel |
| iris | Biometrie met irisscan |
| otp | Eenmalig wachtwoord |
| Pop | Proof of Possession |
| netvlies | Biometrie van netvliesscan |
| Sc | Smartcard |
| sms | Bevestiging per tekst naar geregistreerd nummer |
| swk | Bevestiging van aanwezigheid van een met software beveiligde sleutel |
| Tel | Bevestiging telefonisch |
| vbm | Biometrie met spraakafdruk |
Microsoft Entra ID vereist dat MFA tevreden is om een token uit te geven met MFA-claims. Als gevolg hiervan kunnen alleen methoden met een ander type voldoen aan de tweede factorvereiste. Zoals eerder vermeld, zijn de verschillende methodetypen die kunnen worden gebruikt om aan de tweede factor te voldoen kennis, bezit en inherentie.
Microsoft Entra ID valideert de typetoewijzing op basis van de volgende tabel.
| Claimmethode | Type | Opmerkingen |
|---|---|---|
| face | Inherence | Biometrie met gezichtsherkenning |
| Fido | Bezit | FIDO2 is gebruikt. Voor sommige implementaties is mogelijk ook biometrische gegevens vereist, maar het type bezitsmethode is toegewezen omdat dit het primaire beveiligingskenmerk is. |
| fpt | Inherence | Biometrie met vingerafdruk |
| hwk | Bezit | Bewijs van het bezit van met hardware beveiligde sleutel |
| iris | Inherence | Biometrie met irisscan |
| otp | Bezit | Eenmalig wachtwoord |
| Pop | Bezit | Proof of Possession |
| netvlies | Inherence | Biometrie van netvliesscan |
| Sc | Bezit | Smartcard |
| sms | Bezit | Bevestiging per tekst naar geregistreerd nummer |
| swk | Bezit | Bewijs van aanwezigheid van een met software beveiligde sleutel |
| Tel | Bezit | Bevestiging telefonisch |
| vbm | Inherence | Biometrie met spraakafdruk |
Als er geen problemen zijn gevonden met het token, beschouwt Microsoft Entra ID MFA als tevreden en geeft een token aan de eindgebruiker uit. Anders mislukt de aanvraag van de eindgebruiker.
Fout wordt aangegeven door parameters voor foutreacties uit te geven.
| Parameter | Weergegeven als | Beschrijving |
|---|---|---|
| Error | Een ASCII-foutcode, zoals access_denied of temporarily_unavailable. |
Microsoft Entra ID beschouwt de aanvraag geslaagd als de parameter id_token aanwezig is in het antwoord en of het token geldig is. Anders wordt de aanvraag als mislukt beschouwd. Microsoft Entra ID mislukt de oorspronkelijke verificatiepoging vanwege de vereiste van het beleid voor voorwaardelijke toegang.
Microsoft Entra ID verlaat de status van de verificatiepoging aan het einde van ongeveer 10 minuten na de omleiding naar de provider.
Afhandeling van Microsoft Entra ID-foutreacties
Microsoft Azure-services gebruiken een correlationId om aanroepen in verschillende interne en externe systemen te correleren. Het fungeert als een algemene id van de hele bewerking of stroom die mogelijk meerdere HTTP-aanroepen omvat. Wanneer er een fout optreedt tijdens een van de bewerkingen, bevat het antwoord een veld met de naam Correlatie-id.
Wanneer u contact opstelt met Microsoft-ondersteuning of een vergelijkbare service, geeft u de waarde van deze correlatie-id op, omdat deze helpt om sneller toegang te krijgen tot de telemetrie en logboeken.
Voorbeeld:
ENTRA IDSTS70002: Fout bij het valideren van referenties. ENTRA IDSTS50012: Externe id-token van verlener 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' is mislukte handtekeningverificatie. KeyID van token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Trace ID: 000aaaa-11bb-cccc-dd22-eeeee333 Correlatie-id33: aaaa0000-bb11-2222-33cc-44444ddddddddd tijdstempel: 2023-07-24 16:51:34Z
Aangepaste besturingselementen en EAM's
In Microsoft Entra ID kunnen aangepaste besturingselementen voor EAM's en voorwaardelijke toegang parallel worden uitgevoerd terwijl klanten zich voorbereiden op en migreren naar EAM's.
Klanten die momenteel gebruikmaken van een integratie met een externe provider met behulp van aangepaste besturingselementen, kunnen deze blijven gebruiken en elk beleid voor voorwaardelijke toegang dat ze hebben geconfigureerd voor het beheren van de toegang. Beheerders worden aanbevolen om een parallelle set beleidsregels voor voorwaardelijke toegang te maken tijdens de migratieperiode:
Voor het beleid moet het besturingselement Meervoudige verificatietoe kennen vereisen worden gebruikt in plaats van de aangepaste besturingselementtoe kennen.
Notitie
Besturingselementen verlenen op basis van verificatiesterkten, waaronder de ingebouwde MFA-sterkte, worden niet tevreden gesteld door de EAM. Beleidsregels moeten alleen worden geconfigureerd met Meervoudige verificatie vereisen. We werken actief aan de ondersteuning van EAM's met verificatiesterkten.
Het nieuwe beleid kan eerst worden getest met een subset van gebruikers. De testgroep wordt uitgesloten van het beleid waarvoor de aangepaste besturingselementen zijn vereist en opgenomen in het beleid waarvoor MFA is vereist. Zodra de beheerder vertrouwd is met het beleid waarvoor MFA is vereist, kan de beheerder alle vereiste gebruikers in het beleid opnemen met de MFA-toekenning en kan het beleid dat is geconfigureerd voor aangepaste besturingselementen worden verplaatst naar Uit.
Integratieondersteuning
Als u problemen ondervindt bij het bouwen van EAM-integratie met Microsoft Entra ID, kan de onafhankelijke leverancier van de oplossing (CxE) van Microsoft Customer Experience Engineering (CxE) mogelijk helpen. Als u contact wilt opnemen met het CxE ISV-team, dient u een aanvraag in voor hulp.
Verwijzingen
Woordenlijst
| Termijn | Omschrijving |
|---|---|
| MFA | Meervoudige verificatie. |
| EAM | Een externe verificatiemethode is een verificatiemethode van een andere provider dan Microsoft Entra-id die wordt gebruikt als onderdeel van het verifiëren van een gebruiker. |
| OIDC | Open ID Connect is een verificatieprotocol op basis van OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc44444 | Een voorbeeld van een appid die is geïntegreerd voor een externe verificatiemethode. |
Volgende stappen
Zie Een externe verificatiemethode beheren in Microsoft (preview) voor meer informatie over het configureren van een EAM in het Microsoft Entra-beheercentrum.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor