Mönstret Federerade identiteter

Delegera användarautentisering till en extern identitetsprovider (IdP) för att förenkla utveckling, minimera administrativa uppgifter och förbättra program-UX.

Kontext och problem

Användare behöver vanligtvis arbeta med flera program som partnerorganisationer tillhandahåller och är värdar för. De kan behöva använda specifika, olika inloggningsuppgifter för varje program. Det här kravet kan:

• Orsaka ett osammanhängande UX. Anställda glömmer ofta flera inloggningsuppgifter.

• Exponera säkerhetsrisker. När en anställd lämnar företaget måste organisationen omedelbart inaktivera kontot. Stora organisationer missar ofta det här kritiska steget.

• Komplicera användarhanteringen. Administratörer hanterar användarautentiseringsuppgifter, utfärdar lösenordspåminnelser och utför andra administrativa uppgifter.

Användare föredrar vanligtvis att använda samma inloggningsuppgifter för alla program.

Lösning

Implementera en mekanism för federerad identitetsautentisering. Separera användarautentisering från programkoden och delegera autentisering till en betrodd IdP. Den här processen förenklar utvecklingen, minimerar administrativa kostnader och ger användarautentisering via en rad IP-adresser. Federerad identitet separerar också autentisering från auktorisering.

Betrodda IP-adresser inkluderar företagskataloger, lokala federationstjänster, säkerhetstokentjänster (STS) och sociala IP-adresser som Microsoft, Google, Yahoo!eller Facebook.

Följande diagram visar mönster för federerad identitet för ett klientprogram som har åtkomst till en tjänst som kräver autentisering. IdP:t fungerar med en STS för att tillhandahålla autentisering. IdP:n utfärdar säkerhetstoken med information om den autentiserade användaren. Den här informationen, som kallas anspråk, innehåller användarens identitet och kan även innehålla andra anspråk, till exempel rollmedlemskap och mer detaljerade åtkomsträttigheter.

Den här modellen kallas även för anspråksbaserad åtkomstkontroll. Applikationer och tjänster beviljar åtkomst till funktioner och funktionalitet baserat på anspråken. Tjänsten som kräver autentisering måste lita på IdP:n. Klientprogrammet kontaktar IdP för autentisering. Om autentisering lyckas returnerar IdP:n en token som innehåller användaridentifierande attribut till STS. IdP och STS kan ingå i samma tjänst. STS kan transformera och utöka anspråken baserat på fördefinierade regler innan token returneras till klienten. Klientprogrammet skickar sedan denna token till tjänsten som bevis på dess identitet.

Federerad autentisering tillhandahåller en standardbaserad metod för att upprätta förtroende för identiteter mellan domäner, och den stöder enkel inloggning (SSO). Många program, särskilt molnbaserade program, använder federerad autentisering eftersom det stöder enkel inloggning utan direkt nätverksanslutning till en IdP. Den här designen ökar säkerheten eftersom användaren inte behöver skapa och ange olika inloggningsuppgifter för flera program. Det begränsar också exponeringen av autentiseringsuppgifter till endast det ursprungliga IdP:t. Program ser endast autentiserad identitetsinformation i token.

Program och tjänster som använder federerad autentisering behöver inte tillhandahålla identitetshanteringsfunktioner. I stället ansvarar IdP för hantering av identiteter och autentiseringsuppgifter. När företagskatalogen litar på IdP:t behöver den inte hantera användaridentiteten. Den här metoden eliminerar de administrativa kostnaderna för katalogbaserad användaridentitetshantering.

Problem och överväganden

Tänk på följande när du bestämmer dig för hur du implementerar det här mönstret:

• Autentisering kan vara en enda felkälla. Om du vill upprätthålla programmets tillförlitlighet och tillgänglighet i flera regioner bör du överväga att distribuera din mekanism för identitetshantering i samma regioner som ditt program.

• Om du vill konfigurera rollbaserad åtkomstkontroll (RBAC) använder du autentiseringsverktyg. RBAC stöder detaljerad kontroll över funktions- och resursåtkomst.

• Till skillnad från en företagskatalog tillhandahåller anspråksbaserad autentisering som använder sociala IP-adresser vanligtvis bara den autentiserade användarens e-postadress och ibland deras namn. Vissa sociala IP-adresser, till exempel Microsoft, tillhandahåller endast en unik identifierare. Programmet behåller vanligtvis viss information om registrerade användare så att den kan matcha den här informationen med identifieraren i anspråken. Den här uppgiften slutförs vanligtvis under registreringen, när användaren först kommer åt programmet. Information matas sedan in i token som nya anspråk efter varje autentisering.

• Om flera IdP:er är konfigurerade för STS måste STS avgöra vilken IdP som ska autentisera användaren. Den här processen kallas identifiering av hemdomän. STS kan fastställa IdP:t automatiskt baserat på användarinformation som en e-postadress eller ett användarnamn, programunderdomänen, användarens IP-adressintervall eller en cookie som lagras i användarens webbläsare. Om användaren till exempel anger en Microsoft e-postadress, till exempel user@live.com, omdirigerar STS användaren till Microsoft-konto inloggningssida. Vid efterföljande besök kan STS använda en cookie som anger att användaren tidigare loggat in med hjälp av en Microsoft-konto. Om STS inte automatiskt kan fastställa hemsfären visas en identifieringssida för hemsfären som visar de betrodda IP-adresserna. Användaren väljer sedan ett IdP.

När du ska använda det här mönstret

Använd det här mönstret när du behöver:

• SSO inom företaget. I det här scenariot måste du autentisera anställda för företagsprogram som finns i molnet utanför företagets säkerhetsgräns, utan inloggning varje gång de besöker ett program. Användarupplevelsen matchar lokala program. Användarna autentiserar när de loggar in på företagsnätverket och kan sedan komma åt relevanta program utan någon annan inloggning.

• Federerad identitet med flera partner. I det här scenariot måste du autentisera företagsanställda och affärspartner som inte har konton i företagskatalogen. Den här metoden är vanlig i företag-till-företag-program, program som integreras med partnertjänster och i företag som använder olika IT-system eller sammanfogade eller delade resurser.

• Federerad identitet i SaaS-program (programvara som en tjänst). I det här scenariot tillhandahåller oberoende programvaruleverantörer en tjänst som är redo att användas för flera klienter eller klienter. Klientorganisationer autentiserar sig med hjälp av en lämplig IdP. Företagsanvändare använder till exempel sina företagsautentiseringsuppgifter, medan klientanvändare och klienter använder autentiseringsuppgifter för sociala identiteter.

• Federerad identitet för åtkomst till arbetslaster. I det här scenariot måste klientprogram, automatiseringsarbetsflöden eller system för kontinuerlig integrering och kontinuerlig leverans anropa dina API:er utan att en användare finns. Klientorganisationer autentiserar via sina egna IP-adresser med hjälp av arbetsbelastningsidentiteter. Programmet auktoriserar åtkomst med hjälp av validering av klientomfattande anspråk.

Det här mönstret kanske inte är lämpligt när du har:

• En IdP. I det här scenariot autentiserar programanvändare med hjälp av ett IdP och de behöver inte autentisera med hjälp av en annan IdP. Den här situationen är typisk för program som använder en företagskatalog för autentisering, antingen via ett VPN eller en virtuell nätverksanslutning mellan programmet och en lokal katalog.

• Inkompatibla autentiseringsmekanismer. I det här scenariot använder programmet en annan autentiseringsmekanism, till exempel genom att använda anpassade användarlager, eller så kan det inte hantera anspråksbaserade teknikförhandlingsstandarder. Det kan vara komplext och dyrt att eftermontera anspråksbaserad autentisering och åtkomstkontroll i ett befintligt program.

Design av arbetsbelastning

Utvärdera hur du använder mönster för federerad identitet i en arbetsbelastnings design för att uppfylla de mål och principer som beskrivs i Azure Well-Architected Framework-pelarna. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

En organisation driver en molnbaserad applikation med flera komponenter som omfattar en webbfrontdel och ett backend-API. Programmet delegerar autentisering till en centraliserad IdP med hjälp av Microsoft Entra ID i stället för att implementera autentiseringslogik i varje komponent.

Ladda ned en Visio-fil av den här arkitekturen.

Följande arbetsflöde motsvarar föregående diagram.

1. Användaren kommer åt webbappen.

2. Webbappen omdirigerar användaren till Microsoft Entra ID för autentisering.

3. Efter lyckad autentisering omdirigerar Microsoft Entra ID användaren tillbaka till webbappen med en auktoriseringskod.

4. Webbappen utbyter auktoriseringskoden för token och skickar en POST-begäran till tokenslutpunkten.

5. Microsoft Entra ID utfärdar en token som innehåller anspråk om användaren.

6. Webbappen använder den här token för att anropa ett serverdels-API.

7. Webbappen och serverdels-API:et verifierar token och tillämpar sina auktoriseringsregler baserat på anspråken.

8. API:et returnerar svaret till webbappen.

Viktiga egenskaper:

• Centraliserad autentisering. Komponenter förlitar sig på Microsoft Entra ID för att autentisera användare, vilket tar bort behovet av anpassad autentiseringslogik i programmet.

• Decentraliserad auktorisering. Programkomponenter framtvingar oberoende auktoriseringsbeslut baserat på anspråk.

• Anspråksbaserad åtkomstkontroll. Åtkomst till funktioner bestäms med hjälp av anspråk, till exempel roller eller omfång.

• Standardbaserade protokoll. Komponenter använder OAuth 2.0 och OpenID Connect för autentisering.

• Valfri MFA-tillämpning. Om riskprofilen kräver en starkare inloggningsgaranti kan du framtvinga multifaktorautentisering med hjälp av principer för villkorsstyrd åtkomst i Microsoft Entra ID.

• Valbar utbyggbarhet genom federering. Microsoft Entra ID kan konfigureras för att lita på en partnerklientorganisation i Microsoft Entra genom att använda åtkomstinställningar mellan klientorganisationer. Partneranvändare kan sedan komma åt programmet utan ändringar i programkomponenter.

Nästa steg

• Vad är Microsoft Entra?
• OpenID Connect i Microsofts identitetsplattform
• Gör om en app för en klientorganisation till en app för flera klientorganisationer med hjälp av Microsoft Entra ID
• Vad är villkorlig åtkomst?

Relaterade resurser

• Arkitekturöverväganden för identitet i en lösning med flera klienter
• Gatekeeper-mönster
• Valet-nyckelmönster
• Gateway-avlastningsmönster