Delegera autentiseringen till en extern identitetsleverantör. Detta kan förenkla utvecklingen, minimera behovet av användaradministration och förbättra användarupplevelsen i programmet.
Kontext och problem
Användare arbetar vanligtvis med flera program från olika organisationer som de har en affärsrelation med. Och användarna måste förmodligen ha specifika (och olika) autentiseringsuppgifter för varje program. Detta kan leda till:
En svårhanterlig användarupplevelse. Det är lätt att användarna glömmer sina inloggningsuppgifter om de har många att hålla reda på.
Säkerhetsrisker. När en användare lämnar företaget måste kontot avetableras omedelbart. Det är lätt att detta glöms bort i stora organisationer.
Att användarhanteringen försvåras. Administratörer hanterar autentiseringsuppgifter för alla användare, samt ytterligare uppgifter som att tillhandahålla lösenordspåminnelser.
Vanligtvis föredrar användare samma autentiseringsuppgifter för alla sina program.
Lösning
Implementera en autentiseringsmekanism som tillämpar federerad identitet. Separera användarautentisering från programkoden och delegera autentisering till en betrodd identitetsleverantör. Detta kan förenkla utvecklingen och tillåta användare att autentiseras med ett större antal identitetsleverantörer (IdP), samtidigt som det administrativa arbetet minskar. Det innebär också att du kan ha en klar separering mellan autentisering och auktorisering.
Betrodda identitetsleverantörer är bland annat företagskataloger, lokala federationstjänster, andra säkerhetstokentjänster (STS) som tillhandahålls av affärspartner, eller sociala identitetsleverantörer som autentiserar användare som till exempel har ett Microsoft-, Google-, Yahoo!- eller Facebook-konto.
Bilden visar mönstret för federerad identitet när ett klientprogram behöver åtkomst till en tjänst som kräver autentisering. Autentiseringen utförs av en IdP som fungerar tillsammans med en STS. IdP:n utfärdar säkerhetstoken med information om den autentiserade användaren. Den här informationen, som kallas anspråk, omfattar användarens identitet och kan även innehålla annan information som rollmedlemskap och mer detaljerade åtkomsträttigheter.
Den här modellen kallas ofta för anspråksbaserad åtkomstkontroll. Program och tjänster beviljar åtkomst till funktioner beroende på vilka anspråk som ingår i en token. Tjänsten som kräver autentisering måste lita på IdP:n. Klientprogrammet kontaktar IdP:n som utför autentiseringen. Om autentiseringen lyckas returnerar IdP:n en token som innehåller anspråken som identifierar användaren till säkerhetstokentjänsten. Observera att IdP och STS kan vara samma tjänst. Säkerhetstokentjänsten kan omvandla och utöka anspråk i en token baserat på fördefinierade regler innan den returneras till klienten. Klientprogrammet kan sedan vidarebefordra denna token till tjänsten som identitetsbevis.
Det kan finnas ytterligare säkerhetstokentjänster i förtroendekedjan. I exempelscenariot som beskrivs senare förlitar en lokal säkerhetstokentjänst sig på en annan säkerhetstokentjänst som ansvarar för åtkomst till en identitetsleverantör för att autentisera användaren. Den här metoden är vanlig i företagssituationer där det finns en lokal säkerhetstokentjänst och katalog.
Sammansluten autentisering är en standardbaserad lösning för att utfärda betrodda identiteter till olika domäner och kan fungera för enkel inloggning. Den här typen av autentisering blir allt vanligare för alla typer av program, särskilt molnbaserade program, eftersom den stöder enkel inloggning utan att kräva en direkt nätverksanslutning till identitetsprovidrar. Användaren behöver inte ange autentiseringsuppgifter för varje program. Detta ökar säkerheten eftersom det förhindrar skapande av autentiseringsuppgifter som krävs för att komma åt många olika program, och det döljer även användarens autentiseringsuppgifter från alla utom den ursprungliga identitetsprovidern. Program har bara tillgång till den autentiserade identitetsinformation som finns i token.
En annan fördel med federerade identiteter är att hanteringen av identiteter och autentiseringsuppgifter är identitetsleverantörens ansvar. Programmet eller tjänsten behöver inte tillhandahålla identitetshanteringsfunktioner. Om ett företag har en betrodd identitetsleverantör behöver heller inte företagskatalogen innehålla information om användaren. Detta eliminerar det administrativa arbetet med att hantera användaridentiteter i katalogen.
Problem och överväganden
Tänk på följande när du skapar program som implementerar sammansluten autentisering:
Autentisering kan vara en felkritisk systemdel. Om du distribuerar programmet till flera datacenter, kan du eventuellt distribuera din identitetshanteringsmekanism till samma datacenter för att upprätthålla programmets tillförlitlighet och tillgänglighet.
Verktyg för autentisering gör det möjligt att konfigurera åtkomstkontroll utifrån rollanspråk som finns i autentiseringstoken. Detta kallas ofta rollbaserad åtkomstkontroll (RBAC) och kan ge mer detaljerad kontroll över åtkomst till funktioner och resurser.
Till skillnad från en företagskatalog innehåller inte anspråksbaserad autentisering med hjälp av sociala identitetsleverantörer annan information om den autentiserade användaren än en e-postadress och möjligen namnet. Vissa sociala identitetsleverantörer, till exempel ett Microsoft-konto, innehåller bara en unik identifierare. Programmet måste vanligtvis lagra viss information om registrerade användare, och kunna matcha informationen med identifieraren i anspråken i en token. Detta görs normalt genom registrering när användaren först använder programmet, och information infogas sedan i gällande token som ytterligare anspråk efter varje autentisering.
Om det finns fler än en identitetsprovider konfigurerad för STS måste STS avgöra vilken identitetsprovider som användaren ska omdirigeras till för autentisering. Den här processen kallas identifiering av startsfär. STS kanske kan göra detta automatiskt baserat på en e-postadress eller ett användarnamn som användaren tillhandahåller, en underdomän för programmet som användaren har åtkomst till, användarens IP-adressomfång eller innehållet i en cookie som lagras i användarens webbläsare. Om användaren till exempel har angett en e-postadress i Microsoft-domänen (som user@live.com), omdirigerar säkerhetstokentjänsten användaren till Microsoft-kontots inloggningssida. Vid påföljande besök kan säkerhetstokentjänsten tillämpa en cookie som visar att den senaste inloggningen var med ett Microsoft-konto. Om startsfären inte kan identifieras automatiskt, visar säkerhetstokentjänsten en sida för identifiering av startsfär med en lista över betrodda identitetsleverantörer och användaren måste välja den som ska användas.
När du ska använda det här mönstret
Det här mönstret är användbart i följande scenarier:
Enkel inloggning i företaget. I det här scenariot måste anställda autentiseras för företagets program som finns i molnet, utanför företagets säkerhetsskydd, utan att behöva logga in varje gång de vill använda ett program. Användarupplevelsen är densamma som för lokala program där de autentiseras vid inloggning till ett företagsnätverk, och därefter har åtkomst till alla relevanta program utan att behöva logga in igen.
Federerad identitet med flera partner. I det här scenariot behöver både företagets anställda och affärspartner som inte har konton i företagskatalogen autentiseras. Det här är vanligt i företag-till-företag-program, program som integreras med tjänster från tredje part och där företag med olika IT-system har sammanslagits eller delar resurser.
Federerad identitet i SaaS-program. I det här scenariot tillhandahåller oberoende programvaruleverantörer tjänster som är klara att användas för flera klienter eller klientorganisationer. Varje klient autentiseras med en lämplig identitetsleverantör. Företagsanvändare använder till exempel sina företagsautentiseringsuppgifter, medan konsumenter och klientorganisationens klienter använder sina sociala autentiseringsuppgifter.
Det här mönstret kanske inte är användbart i följande situationer:
Alla som använder programmet kan autentiseras av en identitetsleverantör och det inte är nödvändigt att autentisera med någon annan identitetsleverantören. Det här är vanligt i affärsprogram som använder en företagskatalog (tillgänglig i programmet) för autentisering med ett VPN, eller (i ett scenario med molnbaserad värd) via en virtuell nätverksanslutning mellan den lokala katalogen och programmet.
Programmet har ursprungligen skapats med en annan autentiseringsmekanism, som anpassade användarbutiker, eller har inte kapacitet att hantera de förhandlingsstandarder som används av anspråksbaserad teknik. Att lägga till anspråksbaserad autentisering och åtkomstkontroll i efterhand i befintliga program kan vara komplicerat och förmodligen inte kostnadseffektivt.
Design av arbetsbelastning
En arkitekt bör utvärdera hur det federerade identitetsmönstret kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Beslut om tillförlitlighetsdesign hjälper din arbetsbelastning att bli motståndskraftig mot fel och se till att den återställs till ett fullt fungerande tillstånd när ett fel inträffar. | När användarhantering och autentisering avlastas ändras tillförlitligheten för dessa komponenter till identitetsprovidern, som vanligtvis har ett högt servicenivåmål. Under haveriberedskapen för arbetsbelastningen behöver autentiseringskomponenter sannolikt inte åtgärdas som en del av återställningsplanen för arbetsbelastningen. - RE:02 Kritiska flöden - RE:09 Haveriberedskap |
| Beslut om säkerhetsdesign bidrar till att säkerställa konfidentialitet, integritet och tillgänglighet för arbetsbelastningens data och system. | Genom att externalisera användarhantering och autentisering kan du få utvecklade funktioner för identitetsbaserad hotidentifiering och skydd utan att behöva implementera dessa funktioner i din arbetsbelastning. Och externa identitetsprovidrar använder moderna kompatibla autentiseringsprotokoll. - SE:02 Säker utvecklingslivscykel - SE:10 Övervakning och hotidentifiering |
| Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. | När du avlastar användarhantering och autentisering kan du ägna programresurser åt andra prioriteringar. - PE:03 Välja tjänster |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Exempel
En organisation är värd för ett SaaS-program (programvara som en tjänst) med flera klientorganisationer i Microsoft Azure. Programmet innehåller en webbplats som klienterna kan använda för att hantera programmet för sina egna användare. Programmet tillåter klientorganisationer att komma åt webbplatsen med hjälp av en federerad identitet som genereras av Active Directory Federation Services (AD FS) (AD FS) när en användare autentiseras av organisationens egen Active Directory.
Bilden visar hur klientorganisationer autentiserar med sin egen identitetsprovider (steg 1), i det här fallet AD FS. När en klientorganisation har autentiserats utfärdar AD FS en token. Klientwebbläsaren vidarebefordrar denna token till SaaS-programmets federationsprovider, som litar på token som utfärdats av klientorganisationens AD FS, för att få tillbaka en token som är giltig för SaaS-federationsprovidern (steg 2). Vid behov utför SaaS-federationsleverantören en omvandling av anspråken i token till anspråk som programmet kan identifiera (steg 3) innan en ny token returneras till klientens webbläsare. Programmet förlitar sig på token som utfärdas av SaaS-federationsleverantören och använder anspråken i denna token för att tillämpa auktoriseringsregler (steg 4).
Klienter behöver inte komma ihåg separata autentiseringsuppgifter för att komma åt programmet, och en administratör på klientorganisationens företag kan i sin egen AD FS konfigurera listan över användare som har åtkomst till programmet.
Nästa steg
- Microsoft Entra ID
- Active Directory Domain Services
- Active Directory Federation Services
- Program med flera klienter i Azure