Patroon voor federatieve identiteit

Gebruikersverificatie delegeren aan een externe id-provider (IdP) om de ontwikkeling te vereenvoudigen, beheertaken te minimaliseren en de toepassings-UX te verbeteren.

Context en probleem

Gebruikers moeten doorgaans werken met meerdere toepassingen die partnerorganisaties bieden en hosten. Mogelijk moeten ze specifieke, verschillende aanmeldingsreferenties voor elke toepassing gebruiken. Deze voorwaarde kan:

Veroorzaak een gefragmenteerde UX. Werknemers vergeten vaak meerdere inloggegevens.
Beveiligingsproblemen blootstellen. Wanneer een werknemer het bedrijf verlaat, moet de organisatie het account onmiddellijk deactiveren. Grote organisaties missen deze kritieke stap vaak.
Ingewikkeld gebruikersbeheer. Beheerders beheren gebruikersreferenties, wachtwoordherinneringen uitgeven en andere beheertaken uitvoeren.

Gebruikers gebruiken doorgaans dezelfde aanmeldingsreferenties voor alle toepassingen.

Solution

Implementeer een mechanisme voor federatieve identiteitsverificatie. Scheid gebruikersverificatie van de toepassingscode en delegeer verificatie naar een vertrouwde IdP. Dit proces vereenvoudigt de ontwikkeling, minimaliseert administratieve overhead en biedt gebruikersverificatie via een reeks ID's. Federatieve identiteit scheidt ook verificatie van autorisatie.

Vertrouwde id's omvatten bedrijfsmappen, on-premises federatieservices, beveiligingstokenservices (STSs) en sociale id's zoals Microsoft, Google, Yahoo!of Facebook.

In het volgende diagram ziet u het patroon Federatieve identiteit voor een clienttoepassing die toegang heeft tot een service waarvoor verificatie is vereist. De IdP werkt met een STS om verificatie te bieden. De IdP geeft beveiligingstokens uit die informatie over de geverifieerde gebruiker verschaffen. Deze informatie, claims genoemd, bevat de identiteit van de gebruiker en kan ook andere claims bevatten, zoals rollidmaatschappen en gedetailleerdere toegangsrechten.

Dit model wordt ook wel toegangsbeheer op basis van claims genoemd. Toepassingen en services autoriseren toegang tot functies en functionaliteit op basis van de claims. De service die verificatie vereist, moet de IdP vertrouwen. De clienttoepassing neemt contact op met de IdP voor verificatie. Als de verificatie slaagt, retourneert de IdP een token met door de gebruiker geïdentificeerde claims aan de STS. De IdP en de STS maken mogelijk deel uit van dezelfde service. De STS kan de claims transformeren en uitbreiden op basis van vooraf gedefinieerde regels voordat het token naar de client wordt geretourneerd. De clienttoepassing geeft dit token vervolgens door aan de service als bewijs van de identiteit.

Federatieve verificatie biedt een op standaarden gebaseerde methode voor het tot stand brengen van vertrouwen in identiteiten tussen domeinen en biedt ondersteuning voor eenmalige aanmelding (SSO). Veel toepassingen, met name in de cloud gehoste toepassingen, gebruiken federatieve verificatie omdat SSO zonder directe netwerkverbinding met een IdP wordt ondersteund. Dit ontwerp verhoogt de beveiliging, omdat de gebruiker geen andere aanmeldingsreferenties hoeft te maken en in te voeren voor meerdere toepassingen. Het beperkt ook de blootstelling van inloggegevens tot de oorspronkelijke IdP. Toepassingen zien alleen de geverifieerde identiteitsgegevens in het token.

Toepassingen en services die gebruikmaken van federatieve verificatie hoeven geen functies voor identiteitsbeheer te bieden. In plaats daarvan is de IdP verantwoordelijk voor identiteits- en referentiebeheer. Wanneer de bedrijfsdirectory de IdP vertrouwt, hoeft deze de gebruikersidentiteit niet te beheren. Deze aanpak elimineert de administratieve overhead van gebruikersidentiteitsbeheer op basis van directory's.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

Authenticatie kan een enkel storingspunt vormen. Als u de betrouwbaarheid en beschikbaarheid van toepassingen in meerdere regio's wilt behouden, kunt u overwegen om uw mechanisme voor identiteitsbeheer in dezelfde regio's als uw toepassing te implementeren.
Gebruik verificatiehulpprogramma's om op rollen gebaseerd toegangsbeheer (RBAC) te configureren. RBAC biedt ondersteuning voor gedetailleerde controle over functie- en resourcetoegang.
In tegenstelling tot een bedrijfsadreslijst biedt op claims gebaseerde verificatie die gebruikmaakt van sociale ID's meestal alleen het e-mailadres van de geverifieerde gebruiker en soms hun naam. Sommige sociale ID's, zoals Microsoft, bieden alleen een unieke id. De toepassing onderhoudt meestal bepaalde informatie over geregistreerde gebruikers, zodat deze informatie kan worden vergeleken met de id in de claims. Deze taak wordt meestal voltooid tijdens de registratie, wanneer de gebruiker de toepassing voor het eerst opent. Na elke verificatie wordt informatie als nieuwe claims in het token geïnjecteerd.
Als er meerdere ID's zijn geconfigureerd voor de STS, moet de STS bepalen welke IdP de gebruiker moet verifiëren. Dit proces wordt home realm discovery genoemd. De STS kan de IdP automatisch bepalen op basis van door de gebruiker verstrekte informatie, zoals een e-mailadres of een gebruikersnaam, het subdomein van de toepassing, het IP-adresbereik van de gebruiker of een cookie die is opgeslagen in de browser van de gebruiker. Als de gebruiker bijvoorbeeld een Microsoft e-mailadres invoert, bijvoorbeelduser@live.com, wordt de gebruiker door de STS omgeleid naar de aanmeldingspagina van de Microsoft-account. Bij volgende bezoeken kan de STS een cookie gebruiken die aangeeft dat de gebruiker zich eerder heeft aangemeld met behulp van een Microsoft-account. Als de STS de thuisrealm niet automatisch kan bepalen, wordt er een detectiepagina voor thuisrealm weergegeven met de vertrouwde ID's. De gebruiker selecteert vervolgens een IdP.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer u het volgende nodig hebt:

SSO binnen de onderneming. In dit scenario moet u werknemers verifiëren voor bedrijfstoepassingen die buiten de bedrijfsbeveiligingsgrens worden gehost in de cloud, zonder dat ze zich telkens hoeven aan te melden wanneer ze een toepassing bezoeken. De gebruikerservaring komt overeen met on-premises toepassingen. Gebruikers verifiëren wanneer ze zich aanmelden bij het bedrijfsnetwerk en vervolgens toegang hebben tot relevante toepassingen zonder een andere aanmelding.
Federatieve identiteit met meerdere partners. In dit scenario moet u zakelijke werknemers en zakenpartners verifiëren die geen accounts hebben in de adreslijst van het bedrijf. Deze praktijk is gebruikelijk in business-to-business-toepassingen, toepassingen die integreren met partnerservices en in bedrijven die gebruikmaken van verschillende IT-systemen of samengevoegde of gedeelde resources.
Federatieve identiteit in SaaS-toepassingen (Software as a Service). In dit scenario bieden onafhankelijke softwareleveranciers een kant-en-klare service voor meerdere clients of tenants. Tenants authenticeren zich via een geschikte IdP. Zakelijke gebruikers gebruiken bijvoorbeeld hun bedrijfsreferenties, terwijl tenantgebruikers en -clients sociale identiteitsreferenties gebruiken.
Federatieve identiteit voor toegang tot workloads. In dit scenario moeten tenanttoepassingen, automatiseringswerkstromen of continue integratie en continue leveringssystemen uw API's aanroepen zonder dat een gebruiker aanwezig is. Tenants authenticeren zich via hun eigen IdP's met behulp van workloadidentiteiten. De toepassing autoriseert toegang door middel van validatie van tenantgebonden claims.

Dit patroon is mogelijk niet geschikt wanneer u het volgende hebt:

Eén IdP. In dit scenario verifiëren toepassingsgebruikers met behulp van één IdP en hoeven ze zich niet te verifiëren met behulp van een andere IdP. Deze situatie is gebruikelijk in toepassingen die een bedrijfsdirectory gebruiken voor verificatie, via een VPN of een virtuele netwerkverbinding tussen de toepassing en een on-premises adreslijst.
Niet-compatibele verificatiemechanismen. In dit scenario maakt de toepassing gebruik van een ander verificatiemechanisme, bijvoorbeeld met behulp van aangepaste gebruikersarchieven, of kan de toepassing geen standaarden voor op claims gebaseerde technologieonderhandeling verwerken. Het kan complex en duur zijn om op claims gebaseerde verificatie en toegangsbeheer aan te passen in een bestaande toepassing.

Ontwerp van werkbelasting

Beoordeel hoe u het federatieve-identiteitspatroon kunt gebruiken bij het ontwerpen van een workload om de doelstellingen en principes te realiseren die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler	Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden.	Dit patroon besteedt gebruikersbeheer en authenticatie uit aan de IdP, die doorgaans een hoge serviceniveaudoelstelling heeft. Tijdens noodherstel van de workload (DR) hoeft het workloadherstelplan geen authenticatieonderdelen te omvatten. - RE:02 Kritieke stromen - RE:09 DR
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen.	Dit patroon biedt geavanceerde mogelijkheden voor detectie en preventie van bedreigingen op basis van identiteit zonder dat u ze in uw workload hoeft te implementeren. Externe IdP's maken ook gebruik van moderne interoperabele authenticatieprotocollen. - Se:02 Beveiligde ontwikkelingslevenscyclus - SE:10 Bewaking en detectie van bedreigingen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code.	Dit patroon helpt u bij het besteden van toepassingsbronnen aan andere prioriteiten. - PE:03 Services selecteren

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Example

Een organisatie host een cloudtoepassing met meerdere onderdelen die een webfront-end en een back-end-API bevat. De toepassing delegeert verificatie naar een gecentraliseerde IdP met behulp van Microsoft Entra ID, in plaats van verificatielogica in elk onderdeel te implementeren.

Een Visio-bestand van deze architectuur downloaden.

De volgende werkstroom komt overeen met het vorige diagram.

De gebruiker heeft toegang tot de web-app.
De web-app leidt de gebruiker om naar Microsoft Entra ID voor verificatie.
Na een geslaagde verificatie stuurt Microsoft Entra ID de gebruiker terug naar de web-app met een autorisatiecode.
De web-app wisselt de autorisatiecode voor tokens uit en verzendt een POST-aanvraag naar het tokeneindpunt.
Microsoft Entra ID geeft een token uit dat claims over de gebruiker bevat.
De web-app gebruikt dit token om een back-end-API aan te roepen.
De web-app en de back-end-API valideren het token en dwingen hun autorisatieregels af op basis van de claims.
De API retourneert het antwoord op de web-app.

Belangrijkste kenmerken:

Gecentraliseerde verificatie. Onderdelen zijn afhankelijk van Microsoft Entra ID voor het verifiëren van gebruikers, waardoor aangepaste verificatielogica in de toepassing niet meer nodig is.
Gedecentraliseerde autorisatie. Toepassingsonderdelen dwingen onafhankelijk autorisatiebeslissingen af op basis van claims.
Toegangsbeheer op basis van claims. Toegang tot functionaliteit wordt bepaald aan de hand van claims, zoals rollen of machtigingen.
Protocollen op basis van standaarden. Onderdelen gebruiken OAuth 2.0 en OpenID Connect voor verificatie.
Optioneel afdwingen van MFA. Als uw risicoprofiel sterkere aanmeldingsgarantie vereist, kunt u meervoudige verificatie afdwingen met behulp van beleid voor voorwaardelijke toegang in Microsoft Entra ID.
Optionele uitbreidbaarheid via federatie. Microsoft Entra ID kan worden geconfigureerd om een partner Microsoft Entra tenant te vertrouwen met behulp van toegangsinstellingen voor meerdere tenants. Partnergebruikers hebben vervolgens toegang tot de toepassing zonder wijzigingen in toepassingsonderdelen.

Volgende stappen

Architectuuroverwegingen voor identiteit in een multitenant-oplossing
Gatekeeper-patroon
Valet Key patroon
Gateway Offloading pattern (Gateway Offloading-patroon)

Feedback

Is deze pagina nuttig?

Last updated on 2026-07-02