Patroon voor federatieve identiteit

Azure Active Directory

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.

An overview of federated authentication

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. Federatieve verificatie wordt steeds vaker gebruikt voor allerlei typen toepassingen, met name toepassingen die in de cloud worden gehost, omdat deze vorm van verificatie eenmalige aanmelding ondersteunt zonder dat daarvoor een rechtstreekse netwerkverbinding met de id-providers nodig is. 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 voor de STS is geconfigureerd, moet de STS bepalen naar welke id-provider de gebruiker moet worden doorgestuurd 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.

Voorbeeld

Een organisatie host een multitenant-SaaS-toepassing 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.

How users at a large enterprise subscriber access the application

In de afbeelding ziet u hoe tenants zich verifiëren met hun eigen id-provider (stap 1), in dit geval AD FS. Na het verifiëren van een tenant 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