Verificatie delegeren aan een externe id-provider. Dat kan het ontwikkeltraject vereenvoudigen, de vereiste voor gebruikersbeheer minimaliseren en de gebruikerservaring van de toepassing verbeteren.
Context en probleem
Gebruikers moeten vaak met meerdere toepassingen werken die verstrekt en gehost worden door verschillende organisaties waarmee ze een zakelijke relatie hebben. Deze gebruikers kunnen worden gevraagd specifieke (en verschillende) referenties voor elk daarvan te gebruiken. Dit kan:
Zorgen voor een onevenwichtige gebruikerservaring. Gebruikers vergeten vaak aanmeldingsreferenties wanneer ze daar veel verschillende van hebben.
Beveiligingsproblemen aan het licht brengen. Wanneer een gebruiker het bedrijf verlaat, moet het account onmiddellijk worden opgeheven. Dit is iets wat in grote organisaties gemakkelijk over het hoofd kan worden gezien.
Gebruikersbeheer bemoeilijken. Beheerders moeten referenties voor alle gebruikers beheren en extra taken uitvoeren zoals het versturen van wachtwoordherinneringen.
Gebruikers hebben liever dezelfde referenties voor al deze toepassingen.
Oplossing
Implementeer een verificatiemethode waarin federatieve identiteiten kunnen worden gebruikt. Scheid gebruikersverificatie van de toepassingscode en delegeer verificatie aan een vertrouwde id-provider. Daardoor wordt de implementatie eenvoudiger en kunnen gebruikers verificatie uitvoeren met behulp van een breed scala aan id-providers (IdP) met een minimum aan administratieve overhead. Hiermee kunt u bovendien verificatie volledig loskoppelen van autorisatie.
De vertrouwde id-providers zijn adreslijsten van het bedrijf, lokale federatieservices, andere beveiligingstokenservices (STS) geleverd door zakelijke partners, of sociale id-providers die gebruikers kunnen verifiëren die bijvoorbeeld een Microsoft-, Google-, Yahoo!- of Facebook-account hebben.
De afbeelding laat het patroon federatieve identiteit zien wanneer een clienttoepassing toegang nodig heeft tot een service die verificatie vereist. De verificatie wordt uitgevoerd door een IdP die samenwerkt met een STS. De IdP geeft beveiligingstokens uit die informatie over de geverifieerde gebruiker verschaffen. Deze informatie, ook wel claims genoemd, bevat de identiteit van de gebruiker en kan ook andere informatie bevatten, zoals rollidmaatschap en gedetailleerdere toegangsrechten.
Dit model wordt vaak aangeduid als toegangsbeheer op basis van claims. Toepassingen en services verlenen toegang aan functies en functionaliteit op basis van de claims in het token. De service die verificatie vereist, moet de IdP vertrouwen. De clienttoepassing neemt contact op met de IdP die de verificatie uitvoert. Als de verificatie is geslaagd, retourneert de IdP een token met de claims waarmee de gebruiker voor de STS wordt geïdentificeerd (de IdP en de STS kunnen overigens dezelfde service zijn). De STS kan de claims in het token transformeren en verbeteren op basis van vooraf gedefinieerde regels voordat het token naar de client wordt teruggestuurd. De clienttoepassing kan dit token dan aan de service doorgeven als bewijs van zijn identiteit.
Er zijn mogelijk extra beveiligingstokenservices in de vertrouwensketen. In het scenario dat verderop wordt beschreven vertrouwt een lokale STS op een andere STS die verantwoordelijk is voor het openen van een id-provider om de gebruiker te verifiëren. Deze aanpak is gebruikelijk in zakelijke scenario's met een on-premises STS en adreslijst.
Federatieve verificatie biedt een op standaarden gebaseerde oplossing voor het probleem om identiteiten in verschillende domeinen te vertrouwen en kan bovendien eenmalige aanmelding ondersteunen. Dit type verificatie wordt steeds vaker gebruikt voor alle soorten toepassingen, met name in de cloud gehoste toepassingen, omdat eenmalige aanmelding wordt ondersteund zonder dat er een directe netwerkverbinding met id-providers is vereist. De gebruiker hoeft geen referenties in te voeren voor elke toepassing. Dit verhoogt de beveiliging, omdat hiermee wordt voorkomen dat referenties worden gemaakt die vereist zijn voor toegang tot veel verschillende toepassingen, en ook de referenties van de gebruiker worden verborgen voor alle id-providers, behalve de oorspronkelijke id-provider. Toepassingen zien alleen de geverifieerde identiteitsinformatie in het token.
Federatieve identiteiten hebben ook het grote voordeel dat beheer van de identiteit en referenties de verantwoordelijkheid van de id-provider is. De toepassing of service hoeft geen functies voor identiteitsbeheer te bieden. Bovendien hoeft in zakelijke scenario's de bedrijfsadreslijst niets over de gebruiker te weten als de id-provider wordt vertrouwd. Hiermee verdwijnt de administratieve overhead van het beheer van de gebruikersidentiteit in de adreslijst.
Problemen en overwegingen
Overweeg het volgende bij het ontwerpen van toepassingen waarin federatieve verificatie wordt geïmplementeerd:
Verificatie kan een Single Point of Failure vormen. Als u uw toepassing in meerdere datacenters implementeert, kunt u uw mechanisme voor identiteitsbeheer in dezelfde datacenters implementeren om de betrouwbaarheid en beschikbaarheid van toepassingen te waarborgen.
Met hulpprogramma's voor verificatie kunt u toegangsbeheer configureren op basis van rolclaims die zijn opgenomen in het verificatietoken. Dit wordt vaak aangeduid als op rollen gebaseerd toegangsbeheer (RBAC) en biedt een gedetailleerder beheer van toegang tot functies en resources.
In tegenstelling tot een bedrijfsadreslijst biedt op claims gebaseerde verificatie met behulp van sociale id-providers meestal geen informatie over de geverifieerde gebruiker anders dan een e-mailadres en misschien een naam. Sommige sociale id-providers, zoals een Microsoft-account, bieden alleen een unieke id. De toepassing moet meestal wat informatie over geregistreerde gebruikers bijhouden en deze informatie kunnen koppelen aan de id die is opgenomen in de claims in het token. Dit vindt doorgaans plaats via registratie wanneer de gebruiker de toepassing de eerste keer opent. Vervolgens wordt de informatie na elke verificatie aan het token doorgegeven als extra claims.
Als er meer dan één id-provider is geconfigureerd voor de STS, moet STS bepalen naar welke id-provider de gebruiker moet worden omgeleid voor verificatie. Dit proces wordt detectie van de thuisrealm genoemd. De STS kan dit mogelijk automatisch doen op basis van een e-mailadres of gebruikersnaam die de gebruiker opgeeft, een subdomein van de toepassing waartoe de gebruiker toegang heeft, het IP-adresbereik van de gebruiker of op de inhoud van een cookie die is opgeslagen in de browser van de gebruiker. Als de gebruiker bijvoorbeeld een e-mailadres in het domein van Microsoft heeft ingevoerd, zoals user@live.com, stuurt de STS de gebruiker door naar de aanmeldingspagina van het Microsoft-account. Bij latere bezoeken kan de STS een cookie gebruiken om aan te geven dat de laatste aanmelding plaatsvond met een Microsoft-account. Als automatische detectie de thuisrealm niet kan bepalen, geeft de STS een pagina voor thuisrealmdetectie weer met vertrouwde id-providers en moet de gebruiker de gewenste optie selecteren.
Wanneer dit patroon gebruiken
Dit patroon is handig voor scenario's zoals:
Eenmalige aanmelding in de onderneming. In dit scenario moet u werknemers verifiëren voor zakelijke toepassingen die worden gehost in de cloud buiten de beveiligingsgrenzen van het bedrijfsnetwerk, zonder dat ze zich hoeven aan te melden telkens wanneer ze een toepassing willen openen. De gebruikerservaring is hetzelfde als bij gebruik van on-premises toepassingen waar gebruikers worden geverifieerd bij aanmelding op een bedrijfsnetwerk en van daaruit toegang hebben tot alle relevante toepassingen zonder zich opnieuw te hoeven aanmelden.
Federatieve identiteit met meerdere partners. In dit scenario moet u zowel eigen werknemers als zakelijke partners verifiëren die geen account in de adreslijst van het bedrijf hebben. Dit is gebruikelijk in B2B-toepassingen, toepassingen die zijn geïntegreerd met services van derden en in situaties waarbij bedrijven met verschillende IT-systemen resources hebben samengevoegd of gedeeld.
Federatieve identiteit in SaaS-toepassingen. In dit scenario bieden onafhankelijke softwareleveranciers een kant-en-klare service voor meerdere clients of tenants. Elke tenant wordt geverifieerd met een geschikte id-provider. Eigen werknemers gebruiken bijvoorbeeld hun bedijfsreferentie, terwijl consumenten en klanten van de tenant hun sociale identiteitsreferentie gebruiken.
Dit patroon is wellicht niet geschikt in de volgende situaties:
Alle gebruikers van de toepassing kunnen met één id-provider worden geverifieerd en verificatie met behulp van andere id-provider is niet vereist. Dit is normaal in zakelijke toepassingen die voor verificatie gebruikmaken van een bedrijfsadreslijst (toegankelijk vanuit de toepassing) met behulp van een VPN of (in een scenario met hosting in de cloud) via een virtuele netwerkverbinding tussen de on-premises adreslijst en de toepassing.
De toepassing was oorspronkelijk bedoeld voor een ander verificatiemechanisme, eventueel met aangepaste gebruikersopslag, of de toepassing kan geen onderhandelingsstandaarden afhandelen die worden gebruikt door technologieën op basis van claims. Verificatie en toegangsbeheer die op claims zijn gebaseerd met terugwerkende kracht invoeren in bestaande toepassingen kan complex en waarschijnlijk ook onrendabel zijn.
Workloadontwerp
Een architect moet evalueren hoe het patroon Federatieve identiteit kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. | Het offloaden van gebruikersbeheer en verificatie verschuift de betrouwbaarheid voor deze onderdelen naar de id-provider, die meestal een hoge SLO heeft. Bovendien hoeven verificatieonderdelen tijdens herstel na noodgevallen van workloads waarschijnlijk niet te worden aangepakt als onderdeel van het herstelplan van de workload. - RE:02 Kritieke stromen - RE:09 Herstel na noodgevallen |
| Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. | Door gebruikersbeheer en verificatie te externaliseren, kunt u ontwikkelmogelijkheden krijgen voor detectie en preventie van bedreigingen op basis van identiteiten zonder dat u deze mogelijkheden in uw workload hoeft te implementeren. En externe id-providers gebruiken moderne interoperabele verificatieprotocollen. - 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 optimalisaties in schalen, gegevens, code. | Wanneer u gebruikersbeheer en verificatie offload, kunt u toepassingsbronnen besteden aan andere prioriteiten. - PE:03 Services selecteren |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
Een organisatie host een SaaS-toepassing (Multitenant Software as a Service) in Microsoft Azure. De toepassing omvat een website die tenants kunnen gebruiken om de toepassing voor hun eigen gebruikers te beheren. Met de toepassing kunnen tenants toegang krijgen tot de website met behulp van een federatieve identiteit die wordt gegenereerd door Active Directory Federation Services (AD FS) wanneer een gebruiker wordt geverifieerd door de eigen Active Directory van die organisatie.
In de afbeelding ziet u hoe tenants verifiëren met hun eigen id-provider (stap 1), in dit geval AD FS. Nadat een tenant is geverifieerd, geeft AD FS een token uit. De clientbrowser stuurt dit token door naar de federatieprovider van de SaaS-toepassing, die tokens vertrouwt die zijn uitgegeven door de AD FS van de tenant om een token terug te krijgen dat geldig is voor de SaaS-federatieprovider (stap 2). De SaaS-federatieprovider voert zo nodig een transformatie voor de claims in het token uit om claims te genereren die de toepassing herkent (stap 3) voordat het nieuwe token wordt teruggestuurd naar de clientbrowser. De toepassing vertrouwt tokens die zijn uitgegeven door de SaaS-federatieprovider en gebruikt de claims in het token om autorisatieregels toe te passen (stap 4).
Tenants hoeven geen afzonderlijke referenties te onthouden voor toegang tot de toepassing en een beheerder van het bedrijf van de tenant kan configureren in zijn eigen AD FS de lijst met gebruikers die toegang hebben tot de toepassing.
Volgende stappen
- Microsoft Entra ID
- Active Directory Domain Services
- Active Directory Federation Services
- Multitenant-toepassingen in Azure