Mönstret Federerade identiteter
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, till exempel 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. Det har blivit allt vanligare för alla typer av program, särskilt molnbaserade program, eftersom det har stöd för enkel inloggning utan att det krävs direkt nätverksanslutning till identitetsleverantörer. Användaren behöver inte ange autentiseringsuppgifter för varje program. Detta ökar säkerheten eftersom det förhindrar skapandet av autentiseringsuppgifter som krävs för åtkomst till 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 fler än en identitetsleverantör har konfigurerats för säkerhetstokentjänsten, måste den identifiera vilken identitetsleverantör användaren ska omdirigeras till för autentisering. Den här processen kallas identifiering av startsfär. StS kan göra detta automatiskt baserat på en e-postadress eller användarnamn som användaren tillhandahåller, en underdomän till 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.
Exempel
En organisation är värd för en programvara som tjänst (SaaS) för flera klienter 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 gör att klienter kan 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 klienter autentiseras med sin egen identitetsprovider (steg 1), i det här AD FS. När du har autentiserat en AD FS en token. Klientwebbläsaren vidarebefordrar denna token till SaaS-programmets federationsprovider, som litar på token som utfärdats av klientens 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 få åtkomst till programmet, och en administratör på klientorganisationens företag kan konfigurera i sin egen AD FS i listan över användare som har åtkomst till programmet.