Dela via

Arkitekturmetoder för identitet i lösningar för flera klientorganisationer

  • Artikel

Nästan alla lösningar för flera klientorganisationer kräver ett identitetssystem. I den här artikeln diskuterar vi vanliga komponenter i identitet, inklusive både autentisering och auktorisering, och vi diskuterar hur dessa komponenter kan användas i en lösning med flera klientorganisationer.

Kommentar

Läs arkitekturöverväganden för identitet i en lösning med flera klienter för att lära dig mer om de viktiga krav och beslut som du behöver fatta innan du börjar skapa ett identitetssystem för en lösning med flera klienter.

Autentisering

Autentisering är den process genom vilken en användares identitet upprättas. När du skapar en lösning för flera klienter finns det särskilda överväganden och metoder för flera aspekter av autentiseringsprocessen.

Federation

Du kan behöva federera med andra identitetsprovidrar (IDP:er). Federation kan användas för att aktivera följande scenarier:

  • Social inloggning, till exempel genom att göra det möjligt för användare att använda sitt Google-, Facebook-, GitHub- eller personliga Microsoft-konto.
  • Klientspecifika kataloger, till exempel genom att göra det möjligt för klientorganisationer att federera ditt program med sina egna identitetsprovidrar, så att de inte behöver hantera konton på flera platser.

Allmän information om federation finns i mönster för federerad identitet.

Om du väljer att stödja klientspecifika identitetsprovidrar måste du klargöra vilka tjänster och protokoll du behöver stöd för. Har du till exempel stöd för OpenID Connect-protokollet och SAML-protokollet (Security Assertion Markup Language) ? Eller kan du bara stödja federering med Microsoft Entra-instanser?

När du implementerar en identitetsprovider bör du överväga alla skalnings- och begränsningar som kan gälla. Om du till exempel använder Azure Active Directory (Azure AD) B2C som din egen identitetsprovider kan du behöva distribuera anpassade principer för att federera med vissa typer av klientidentitetsproviders. Azure AD B2C begränsar antalet anpassade principer som du kan distribuera, vilket kan begränsa antalet klientspecifika identitetsprovidrar som du kan federera med.

Du kan också överväga att tillhandahålla federation som en funktion som endast gäller för kunder på en högre produktnivå.

Enkel inloggning

Med funktioner för enkel inloggning kan användare växla mellan program sömlöst, utan att uppmanas att autentisera på nytt vid varje tidpunkt.

När användare besöker ett program dirigerar programmet dem till en IdP. Om IdP:n ser att de har en befintlig session utfärdar den en ny token utan att användarna behöver interagera med inloggningsprocessen. En federerad identitetsmodell stöder funktioner för enkel inloggning genom att göra det möjligt för användare att använda en enda identitet i flera program.

I en lösning med flera klientorganisationer kan du också aktivera en annan form av enkel inloggning. Om användarna har behörighet att arbeta med data för flera klientorganisationer kan du behöva tillhandahålla en smidig upplevelse när användarna ändrar sin kontext från en klientorganisation till en annan. Överväg om du behöver stöd för sömlösa övergångar mellan klienter, och i så fall om din identitetsprovider behöver återisera token med specifika klientanspråk. En användare som har loggat in på Azure Portal kan till exempel växla mellan olika Microsoft Entra-kataloger, vilket orsakar omautentisering, och den återutger token från den nyligen valda Microsoft Entra-instansen.

Utvärdering av inloggningsrisk

Moderna identitetsplattformar stöder en riskbedömning under inloggningsprocessen. Om en användare till exempel loggar in från en ovanlig plats eller enhet kan autentiseringssystemet kräva extra identitetskontroller, till exempel multifaktorautentisering (MFA), innan inloggningsbegäran kan fortsätta.

Fundera på om dina klienter kan ha olika riskprinciper som måste tillämpas under autentiseringsprocessen. Om du till exempel har vissa klienter i en strikt reglerad bransch kan de ha olika riskprofiler och krav för klienter som arbetar i mindre reglerade miljöer. Eller så kan du välja att tillåta klientorganisationer på högre prisnivåer att ange mer restriktiva inloggningsprinciper än klienter som köper en lägre nivå av din tjänst.

Om du behöver stöd för olika riskprinciper för varje klientorganisation måste autentiseringssystemet veta vilken klientorganisation användaren loggar in på, så att det kan tillämpa rätt principer.

Om din IdP innehåller dessa funktioner kan du överväga att använda IdP:ts interna funktioner för riskbedömning för inloggning. De här funktionerna kan vara komplexa och felbenägna för att implementera dig själv.

Om du federerar till klientorganisationens egna identitetsprovidrar kan du också använda egna riskfyllda policyer för att minska risken för inloggning och de kan styra de principer och kontroller som ska tillämpas. Det är dock viktigt att undvika att oavsiktligt lägga onödig börda på användaren, till exempel genom att kräva två MFA-utmaningar – en från användarens hemidentitetsprovider och en från din egen. Se till att du förstår hur federation interagerar med var och en av dina klientorganisationers identitetsprovidrar och de principer som de har tillämpat.

Personifiering

Personifiering gör det möjligt för en användare att anta identiteten för en annan användare, utan att använda användarens autentiseringsuppgifter.

I allmänhet är personifiering farligt och det kan vara svårt att implementera och kontrollera. Men i vissa scenarier är personifiering ett krav. Om du till exempel använder programvara som en tjänst (SaaS) kan supportpersonalen behöva anta en användares identitet så att de kan logga in som användare och felsöka ett problem.

Om du väljer att implementera personifiering bör du överväga hur du granskar dess användning. Se till att loggarna innehåller både den faktiska användaren som utförde åtgärden och identifieraren för den användare som de personifierade.

Vissa identitetsplattformar stöder personifiering, antingen som en inbyggd funktion eller med hjälp av anpassad kod. I Azure AD B2C kan du till exempel lägga till ett anpassat anspråk för det personifierade användar-ID:t eller ersätta ämnesidentifieraranspråket i de token som utfärdas.

Auktorisering

Auktorisering är processen för att avgöra vad en användare får göra.

Auktoriseringsdata kan lagras på flera platser, bland annat på följande platser:

  • I din identitetsprovider. Om du till exempel använder Microsoft Entra-ID som identitetsprovider kan du använda funktioner som approller och grupper för att lagra auktoriseringsinformation. Ditt program kan sedan använda de associerade tokenanspråken för att framtvinga dina auktoriseringsregler.
  • I ditt program. Du kan skapa din egen auktoriseringslogik och sedan lagra information om vad varje användare kan göra i en databas eller ett liknande lagringssystem. Du kan sedan utforma detaljerade kontroller för rollbaserad eller resursnivåauktorisering.

I de flesta lösningar för flera klienter hanteras roll- och behörighetstilldelningar av klientorganisationen eller kunden, inte av dig som leverantör av multitenantsystemet.

Mer information finns i Programroller.

Lägga till information om klientidentitet och roll i token

Överväg vilken del eller vilka delar av din lösning som ska utföra auktoriseringsbegäranden, inklusive att avgöra om en användare får arbeta med data från en specifik klientorganisation.

En vanlig metod är att ditt identitetssystem bäddar in ett klientidentifieraranspråk i en token. Med den här metoden kan ditt program inspektera anspråket och kontrollera att användarna arbetar med den klientorganisation som de har åtkomst till. Om du använder den rollbaserade säkerhetsmodellen kan du välja att utöka token med information om den roll som en användare har i klientorganisationen.

Men om en enskild användare får åtkomst till flera klienter kan du behöva ett sätt för användarna att signalera vilken klientorganisation de planerar att arbeta med under inloggningsprocessen. När de har valt sin aktiva klientorganisation kan IdP innehålla rätt anspråk och roll för klientorganisationen i den token som problemet gäller. Du måste också överväga hur användare kan växla mellan klienter, vilket kräver att du utfärdar en ny token.

Programbaserad auktorisering

En alternativ metod är att göra identitetssystemet agnostiskt för klientidentifierare och roller. Användarna identifieras med sina autentiseringsuppgifter eller en federationsrelation, och token inkluderar inte ett anspråk för klientidentifierare. En separat lista eller databas innehåller vilka användare som har beviljats åtkomst till varje klientorganisation. Sedan kan programnivån kontrollera om den angivna användaren ska ha åtkomst till data för en specifik klientorganisation, baserat på att leta upp listan.

Använda Microsoft Entra ID eller Azure AD B2C

Microsoft tillhandahåller Microsoft Entra ID, Microsoft Entra External ID och Azure AD B2C, som är hanterade identitetsplattformar som du kan använda i din egen lösning för flera klientorganisationer.

Många lösningar för flera klientorganisationer är SaaS (programvara som en tjänst). Ditt val av om du vill använda Microsoft Entra-ID, Externt Microsoft Entra-ID eller Azure AD B2C beror delvis på hur du definierar dina klientorganisationer eller kundbaser.

  • Om dina klienter eller kunder är organisationer kanske de redan använder Microsoft Entra-ID för tjänster som Office 365, Microsoft Teams eller för sina egna Azure-miljöer. Du kan skapa ett program med flera klientorganisationer i din egen Microsoft Entra-katalog för att göra din lösning tillgänglig för andra Microsoft Entra-kataloger. Du kan till och med lista din lösning på Azure Marketplace och göra den lättillgänglig för organisationer som använder Microsoft Entra-ID.
  • Om dina klienter eller kunder inte använder Microsoft Entra-ID, eller om de är individer snarare än organisationer, kan du överväga att använda Microsoft Entra Externt ID eller Azure AD B2C. Både Microsoft Entra External ID och Azure AD B2C tillhandahåller en uppsättning funktioner för att styra hur användare registrerar sig och loggar in. Du kan till exempel begränsa åtkomsten till din lösning bara för användare som du redan har bjudit in, eller så kan du tillåta självbetjäningsregistrering. Använd anpassade principer i Azure AD B2C för att helt styra hur användare interagerar med identitetsplattformen. Du kan använda anpassad varumärkesanpassning och du kan federera Azure AD B2C med din egen Microsoft Entra-klient för att göra det möjligt för din egen personal att logga in. Azure AD B2C möjliggör även federation med andra identitetsprovidrar.
  • Vissa lösningar för flera klientorganisationer är avsedda för båda de situationer som anges ovan. Vissa klienter kan ha sina egna Microsoft Entra-klienter, och andra kanske inte har det. Du kan också använda Azure AD B2C för det här scenariot och använda anpassade principer för att tillåta användarinloggning från en klientorganisations Microsoft Entra-katalog. Men om du använder anpassade principer för att upprätta federation mellan klienter bör du se till att du överväger gränserna för antalet anpassade principer som en enda Azure AD B2C-katalog kan använda.

Mer information finns i Överväganden för att använda Azure Active Directory B2C i en arkitektur med flera klienter.

Antimönster att undvika

Skapa eller köra ett eget identitetssystem

Det är komplext att skapa en modern identitetsplattform. Det finns en rad olika protokoll och standarder att stödja, och det är enkelt att felaktigt implementera ett protokoll och exponera en säkerhetsrisk. Standarder och protokoll ändras, och du måste också kontinuerligt uppdatera ditt identitetssystem för att minimera attacker och för att stödja de senaste säkerhetsfunktionerna. Det är också viktigt att se till att ett identitetssystem är motståndskraftigt, eftersom eventuella driftstopp kan få allvarliga konsekvenser för resten av din lösning. Dessutom lägger implementeringen av en identitetsprovider i de flesta fall inte till någon förmån för företaget, och det är helt enkelt en nödvändig del av implementeringen av en tjänst för flera klientorganisationer. Det är bättre att i stället använda ett specialiserat identitetssystem som är byggt, drivs och skyddas av experter.

När du kör ett eget identitetssystem måste du lagra lösenordshashvärden eller andra former av autentiseringsuppgifter, vilket blir ett frestande mål för angripare. Även hash- och saltningslösenord är ofta otillräckligt skydd, eftersom den beräkningskraft som är tillgänglig för angripare kan göra det möjligt att kompromettera dessa typer av autentiseringsuppgifter.

När du kör ett identitetssystem ansvarar du också för att generera och distribuera MFA- eller engångslösenordkoder (OTP). Dessa krav innebär att du behöver en mekanism för att distribuera dessa koder med hjälp av SMS eller e-post. Dessutom ansvarar du för att identifiera både riktade och råstyrkeattacker, begränsning av inloggningsförsök, granskning och så vidare.

I stället för att skapa eller köra ett eget identitetssystem är det en bra idé att använda en tjänst eller komponent utanför hyllan. Överväg till exempel att använda Microsoft Entra ID eller Azure AD B2C, som är hanterade identitetsplattformar. Leverantörer av hanterade identitetsplattformar tar ansvar för att driva infrastrukturen för sina plattformar och stöder vanligtvis de aktuella identitets- och autentiseringsstandarderna.

Det går inte att ta hänsyn till dina klientorganisationers krav

Klienter har ofta starka åsikter om hur identiteter ska hanteras för de lösningar de använder. Många företagskunder kräver till exempel federation med sina egna identitetsprovidrar, för att aktivera funktioner för enkel inloggning och för att undvika att hantera flera uppsättningar autentiseringsuppgifter. Andra klienter kan kräva multifaktorautentisering eller andra former av skydd kring inloggningsprocesserna. Om du inte har utformat för dessa krav kan det vara svårt att eftermontera dem senare.

Se till att du förstår klientorganisationens identitetskrav innan du slutför utformningen av ditt identitetssystem. Granska arkitekturöverväganden för identitet i en lösning med flera klienter för att förstå vissa specifika krav som ofta uppstår.

Sammanfla användare och klientorganisationer

Det är viktigt att du tydligt överväger hur din lösning definierar en användare och en klientorganisation. I många situationer kan relationen vara komplex. En klientorganisation kan till exempel innehålla flera användare och en enskild användare kan ansluta till flera klienter.

Se till att du har en tydlig process för att spåra klientkontexten, i ditt program och dina begäranden. I vissa situationer kan den här processen kräva att du inkluderar en klientidentifierare i varje åtkomsttoken och att du verifierar klientidentifieraren för varje begäran. I andra situationer lagrar du information om klientauktorisering separat från användaridentiteterna, och du använder ett mer komplext auktoriseringssystem för att hantera vilka användare som kan utföra vilka åtgärder som klientorganisationer mot.

Spårning av klientkontexten för en användare eller token gäller för alla innehavarmodeller, eftersom en användaridentitet alltid har en klientkontext i en lösning med flera klienter. Det är till och med en bra idé att spåra klientkontexten när du distribuerar oberoende stämplar för en enskild klientorganisation, vilket framtidssäkrar din kodbas för andra former av flera klientorganisationer.

Sammanfla roll- och resursauktorisering

Det är viktigt att du väljer en lämplig auktoriseringsmodell för din lösning. Rollbaserade säkerhetsmetoder kan vara enkla att implementera, men resursbaserad auktorisering ger mer detaljerad kontroll. Överväg dina klientorganisationers krav och om dina klienter behöver auktorisera vissa användare för att få åtkomst till specifika delar av din lösning, och inte andra delar.

Det går inte att skriva granskningsloggar

Granskningsloggar är ett viktigt verktyg för att förstå din miljö och hur användarna implementerar systemet. Genom att granska varje identitetsrelaterad händelse kan du ofta avgöra om ditt identitetssystem är under attack och du kan granska hur systemet används. Se till att du skriver och lagrar granskningsloggar i ditt identitetssystem. Överväg om lösningens identitetsgranskningsloggar ska göras tillgängliga för klienter att granska.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Nästa steg

Granska arkitekturöverväganden för identitet i en lösning med flera klienter.