Arkitekturöverväganden för identitet i en lösning med flera klienter

Identitet är en viktig aspekt av alla lösningar för flera klientorganisationer. Identitetskomponenterna i ditt program ansvarar för följande uppgifter:

• Verifiera en användares identitet, så kallad autentisering

• Tillämpa en användares behörigheter inom ramen för en klientorganisation, som kallas auktorisering

Dina kunder kanske också vill tillåta externa program att komma åt sina data eller integrera med din lösning. En användares identitet avgör vilken information en användare eller tjänst kan komma åt. Det är viktigt att du överväger dina identifieringskrav för att isolera din applikation och dina data mellan klientorganisationer.

Innan du definierar en identitetsstrategi för flera klientorganisationer bör du först överväga följande identitetskrav på hög nivå för din tjänst:

• Avgör om användare eller arbetsbelastningsidentiteter har åtkomst till ett enda program eller flera program i en produktfamilj. Vissa produktfamiljer kan innehålla olika program som delar samma identitetsinfrastruktur, till exempel kassasystem och lagerhanteringsplattformar.

• Fundera på om din lösning implementerar moderna autentiserings- och auktoriseringsstandarder, till exempel OAuth2 och OpenID Connect.

• Utvärdera om autentisering är begränsad till användargränssnittsbaserade program eller om API-åtkomst även gäller för klientorganisationer och tredjepartssystem.

• Avgör om hyresgäster behöver federera med sina egna IdP:er och om flera IdP:er måste stödjas för varje hyresgäst. Du kan till exempel ha klienter med Microsoft Entra-ID, Auth0 och Active Directory Federation Services där varje klientorganisation federerar med din lösning. Identifiera vilka federationsprotokoll som deras IP-adresser använder eftersom dessa protokoll avgör vad din IdP måste stödja.

• Granska eventuella tillämpliga efterlevnadskrav som de behöver uppfylla, till exempel den allmänna dataskyddsförordningen (GDPR) som formar din identitetsstrategi.

• Avgör om klientorganisationer kräver att identitetsdata lagras i specifika geografiska regioner för att uppfylla juridiska, kompatibilitetsmässiga eller operativa behov.

• Utvärdera om användare kommer åt data från flera klienter i programmet. Om de gör det kan du behöva ha stöd för sömlös klientväxling eller tillhandahålla konsoliderade vyer mellan klientorganisationer för specifika användare. Användare som loggar in på Azure-portalen kan till exempel enkelt växla mellan olika Microsoft Entra ID-kataloger och prenumerationer som de har åtkomst till.

När du upprättar dina krav på hög nivå kan du börja planera mer specifik information och krav, till exempel användarkatalogkällor och registrerings- och inloggningsflöden.

Identitetskatalog

För att en lösning med flera klientorganisationer ska kunna autentisera och auktorisera en användare eller tjänst behöver den en plats där identitetsinformation lagras. En katalog kan innehålla auktoritativa poster för varje identitet. Eller så kan den innehålla referenser till externa identiteter som lagras i katalogen för en annan IdP.

När du utformar ett identitetssystem för din lösning för flera klienter måste du överväga vilka av följande typer av IdP som dina klienter och kunder kan behöva:

• Lokalt IdP: Med en lokal IdP kan användare registrera sig för tjänsten. Användarna anger ett användarnamn, en e-postadress eller en identifierare, till exempel ett belöningskortnummer. De tillhandahåller också en autentiseringsuppgift, till exempel ett lösenord. IdP:t lagrar både användaridentifieraren och autentiseringsuppgifterna.

• Social IdP: Med en social IdP kan användare använda en identitet som de har på ett socialt nätverk eller annan offentlig IdP, till exempel Facebook, Google eller ett personligt Microsoft-konto. Sociala IdP används ofta i B2C SaaS-lösningar.

• Klientorganisationens Microsoft Entra ID-katalog: I många saaS-lösningar (business-to-business) (B2B) kanske klientorganisationer redan har en egen Microsoft Entra-ID-katalog, och de kanske vill att din lösning ska använda deras katalog som IdP för att komma åt din lösning. Den här metoden är möjlig när din lösning skapas som ett Microsoft Entra-program med flera klientorganisationer.

• Federation med en klientorganisations IdP: I vissa B2B SaaS-lösningar kan klientorganisationer ha en egen IdP, förutom Microsoft Entra-ID, och de kanske vill att din lösning ska federeras med den. Federation möjliggör enkel inloggning (SSO). Det gör det också möjligt för klientorganisationer att hantera livscykel- och säkerhetsprinciper för sina användare oberoende av din lösning.

Du bör överväga om dina klienter behöver stöd för flera IP-adresser. En enskild klientorganisation kan till exempel behöva stöd för lokala identiteter, sociala identiteter och federerade identiteter. Detta krav är typiskt när företag använder en lösning som är avsedd för både anställda och entreprenörer. De kan använda federation för att ge anställda åtkomst, samtidigt som de ger åtkomst för entreprenörer eller användare som inte har konton i den federerade IdP:t.

Lagra information om autentisering och klientauktorisering

I en lösning med flera klientorganisationer måste du överväga var du ska lagra flera typer av identitetsinformation, inklusive följande typer:

• Information om användar- och tjänstkonton, inklusive deras namn och annan information som dina klienter behöver.

• Information som krävs för att autentisera dina användare på ett säkert sätt, inklusive information för multifaktorautentisering (MFA).

• Klientspecifik information, till exempel klientroller och behörigheter, för auktorisering.

Överväg följande alternativ för att lagra identitetsinformation:

• Lagra all identitets- och auktoriseringsinformation i IdP-katalogen och dela den mellan flera klienter.

• Lagra användarautentiseringsuppgifter i IdP-katalogen. Lagra auktoriseringsdata på programnivån, tillsammans med klientinformation.

Fastställa antalet identiteter för en användare

Lösningar med flera klienter tillåter ofta att en användar- eller arbetsbelastningsidentitet får åtkomst till programresurser och data i flera klientorganisationer. När den här metoden krävs bör du tänka på följande faktorer:

• Bestäm om du vill skapa en enskild användaridentitet för varje person eller skapa separata identiteter för varje kombination av klientorganisation och användare.

  • Använd en enda identitet för varje person när det är möjligt. Det förenklar kontohanteringen för både lösningsleverantören och användarna. Dessutom förlitar sig många av de intelligenta hotskydd som moderna IP-adresser tillhandahåller på att varje person har ett enda användarkonto.

  • Använd flera distinkta identiteter i vissa scenarier. Om personer till exempel använder ditt system både för arbete och för personliga ändamål kanske de vill separera sina användarkonton. Eller om dina klienter har strikta reglerande eller geografiska datalagringskrav kan de kräva att en person har flera identiteter så att de kan följa regler eller lagar.

• Undvik att lagra autentiseringsuppgifter flera gånger om du använder identiteter per klientorganisation. Användarna bör ha sina autentiseringsuppgifter lagrade mot en enda identitet och du bör använda funktioner som gästidentiteter för att referera till samma användarautentiseringsuppgifter från flera klientorganisationers identitetsposter.

Ge användare åtkomst till klientdata

Fundera på hur du planerar att koppla användare till en klientorganisation. Under registreringsprocessen kan du till exempel ange en unik inbjudningskod som användarna kan ange när de får åtkomst till en klientorganisation för första gången. I vissa lösningar kan domännamnet för användarens e-postadress för registrering identifiera deras associerade klientorganisation. Du kan också använda ett annat attribut från användarens identitetsregister för att fastställa klientmappningen. Den här associationen bör sedan lagras baserat på oföränderliga, unika identifierare för både klientorganisationen och användaren.

Om din lösning begränsar varje användare till att komma åt data för en enskild klientorganisation bör du överväga följande beslut:

• Avgör hur IdP identifierar vilken klientorganisation en användare har åtkomst till.

• Förklara hur IdP:t kommunicerar klientidentifieraren till programmet. Vanligtvis läggs ett hyresgästidentifieringsanspråk till i token.

Om en enskild användare behöver beviljas åtkomst till flera klienter bör du överväga följande beslut:

• Lösningen måste ha stöd för logik för att identifiera användare och bevilja lämpliga behörigheter mellan klienter. En användare kan till exempel ha administrativa rättigheter i en klient men begränsad åtkomst i en annan klientorganisation. Anta till exempel att en användare har registrerat sig med en social identitet och sedan beviljats åtkomst till två klienter. Hyresgäst A berikade användarens identitet med mer information. Ska klient B ha åtkomst till den berikade informationen?

• En tydlig mekanism bör göra det möjligt för användare att växla mellan hyresgäster. Den här metoden säkerställer en smidig användarupplevelse och förhindrar oavsiktlig åtkomst mellan klientorganisationer.

• Arbetsbelastningsidentiteter, om du använder dem, måste ange vilken klientorganisation de försöker komma åt. Det här kravet kan omfatta inbäddning av klientspecifik kontext i autentiseringsbegäranden.

• Överväg om klientspecifik information som lagras i en användares identitetspost oavsiktligt kan läcka mellan klienter. Om en användare till exempel registrerar sig med en social identitet och får åtkomst till två klienter, och Klient A berikar användarprofilen, avgör du om klient B ska ha åtkomst till den berikade informationen.

Registreringsprocess för användare för lokala identiteter eller sociala identiteter

Vissa hyresgäster kan behöva tillåta användarna att registrera sig som användare i din lösning. Självbetjäningsregistrering kan vara nödvändig om du inte behöver federation med klientens IdP. Om en självregistreringsprocess behövs bör du överväga följande faktorer:

• Definiera vilka identitetskällor som användare får registrera sig från. Du kan till exempel avgöra om användare kan skapa en lokal identitet och även använda en social IdP.

• Ange om din lösning endast tillåter specifika e-postdomäner om lokala identiteter används. Du kan till exempel avgöra om en klientorganisation kan begränsa registreringar till användare med en @contoso.com e-postadress.

• Det användarhuvudnamn (UPN) som används för att identifiera lokala identiteter måste vara tydligt fastställt. Vanliga UPN:er omfattar e-postadresser, användarnamn, telefonnummer eller medlemskapsidentifierare. Eftersom UPN kan ändras rekommenderar vi att du refererar till den underliggande oföränderliga unika identifieraren för auktorisering och granskning. Ett exempel är objekt-ID (OID) i Microsoft Entra-ID.

• Verifiering av UPN kan krävas för att säkerställa att de är korrekta. Den här processen kan omfatta verifiering av ägarskapet för en e-postadress eller ett telefonnummer innan åtkomst beviljas.

• Vissa lösningar kan kräva att klientadministratörer godkänner användarregistreringar. Den här godkännandeprocessen möjliggör administrativ kontroll över vem som ansluter till en klientorganisation.

• Bestäm om hyresgäster behöver en hyresgästspecifik registreringsupplevelse eller URL. Ta till exempel reda på om dina klienter kräver en varumärkesanpassad registreringsupplevelse när användare registrerar sig eller möjligheten att fånga upp en registreringsbegäran och utföra extra validering innan den fortsätter.

Hyresgäståtkomst för självregistrerade användare

Om användarna kan skapa en identitet själva, definiera en process för att ge dem åtkomst till en hyresgäst. Registreringsflödet kan innehålla en manuell åtkomstbeviljande process eller en automatiserad process baserat på information om användarna, till exempel deras e-postadresser. Det är viktigt att planera för den här processen och ta hänsyn till följande faktorer:

• Definiera hur registreringsflödet avgör att en användare beviljas åtkomst till en specifik klientorganisation.

• Definiera om din lösning automatiskt återkallar användaråtkomst till en hyresgäst när det är lämpligt. När användarna till exempel lämnar en organisation bör det finnas en manuell eller automatiserad process för att ta bort deras åtkomst.

• Ange en funktion för användargranskning så att klientorganisationer kan granska vilka användare som har åtkomst till sin miljö och förstå sina tilldelade behörigheter.

Automatiserad livscykelhantering för konton

Ett vanligt krav för företags- eller företagskunder i en lösning är en uppsättning funktioner som gör det möjligt för dem att automatisera registrering och avregistrering av konton. Öppna protokoll, till exempel System for Cross-Domain Identity Management (SCIM) ger en branschstandardmetod för automatisering. Den här automatiserade processen omfattar vanligtvis skapande och borttagning av identitetsposter och hantering av klientbehörigheter. Tänk på följande faktorer när du implementerar automatiserad livscykelhantering för konton i en lösning med flera klientorganisationer:

• Avgör om dina kunder behöver konfigurera och hantera en automatiserad livscykelprocess för varje klientorganisation. När en användare till exempel registreras kan du behöva skapa identiteten i flera klientorganisationer i ditt program, där varje klientorganisation har en annan uppsättning behörigheter.

• Avgör om du behöver implementera SCIM eller erbjuda federation. Federation gör det möjligt för organisationer att behålla kontrollen över användarhantering genom att hålla sanningskällan inom sina egna system, istället för att hantera lokala användare i din lösning.

Användarautentiseringsprocess

När en användare loggar in på ett program med flera klientorganisationer autentiserar ditt identitetssystem användaren. Tänk på följande när du planerar din autentiseringsprocess:

• Vissa klienter kan kräva möjligheten att konfigurera sina egna MFA-principer. Om dina klienter till exempel är i branschen för finansiella tjänster måste de implementera strikta MFA-principer, medan en liten onlineåterförsäljare kanske inte har samma krav.

• Alternativet att definiera anpassade regler för villkorlig åtkomst kan vara viktigt för hyresgäster. Olika klienter kan till exempel behöva blockera inloggningsförsök från specifika geografiska regioner.

• Avgör om hyresgäster behöver anpassa inloggningsprocessen individuellt. Din lösning kan till exempel behöva visa en kunds logotyp. Eller så kan den behöva hämta användarinformation, till exempel ett belöningsnummer, från ett annat system och returnera den till IdP:t för att utöka användarprofilen.

• Vissa användare kan behöva personifiera andra användare. En supportmedlem kanske till exempel vill undersöka ett problem som en annan användare har genom att personifiera sitt användarkonto utan att behöva autentisera sig som användare.

• API-åtkomst kan krävas för vissa användare eller externa program. De här scenarierna kan vara att anropa lösningens API:er direkt, vilket kringgår standardflöden för användarautentisering.

Belastningsidentiteter

I de flesta lösningar representerar en identitet ofta en användare. Vissa system med flera klienter tillåter också att arbetsbelastningsidentiteter används av tjänster och program för att få åtkomst till dina programresurser. Dina klienter kan till exempel behöva komma åt ett API som din lösning tillhandahåller så att de kan automatisera sina hanteringsuppgifter.

Microsoft Entra stöder arbetsbelastningsidentiteter, och andra identitetsleverantörer stöder dem också ofta.

Arbetsbelastningsidentiteter liknar användaridentiteter, men vanligtvis kräver de olika autentiseringsmetoder, till exempel nycklar eller certifikat. Arbetsbelastningsidentiteter använder inte MFA. I stället kräver arbetsbelastningsidentiteter vanligtvis andra säkerhetskontroller, till exempel vanlig nyckelrullning och förfallotid för certifikat.

Om dina klienter kan aktivera arbetsbelastningsspecifik identitetsåtkomst till din lösning med flera klienter bör du överväga följande faktorer:

• Avgör hur arbetsbelastningsidentiteter skapas och hanteras i varje klientorganisation.

• Bestäm hur begäranden om arbetsbelastningsidentiteter ska begränsas till klienten.

• Utvärdera om du behöver begränsa antalet arbetsbelastningsidentiteter som varje klientorganisation skapar.

• Kontrollera om kontroller för villkorlig åtkomst krävs för tjänsteidentifieringar i varje organisation. En hyresgäst kanske till exempel vill hindra en arbetsflödesidentitet från att autentiseras utanför en viss region.

• Identifiera vilka säkerhetskontroller du tillhandahåller hyresgäster för att säkerställa att arbetsbelastningsidentiteter förblir säkra. Automatiserad nyckelrullning, nyckelförfallodatum, certifikatets giltighetstid och övervakning av inloggningsrisker bidrar till att minska risken för missbruk av arbetsbelastningsidentitet.

Federera med en IdP för enkel inloggning

Klienter som redan har egna användarkataloger kanske vill att din lösning ska federeras till deras kataloger. Med federation kan din lösning använda identiteterna i deras katalog i stället för att hantera en annan katalog med distinkta identiteter.

Federation är särskilt viktigt när vissa klienter vill ange sina egna identitetsprinciper eller aktivera SSO-upplevelser.

Om du förväntar dig att klientorganisationer federerar med din lösning bör du tänka på följande faktorer:

• Överväg processen för att konfigurera federationen för en klientorganisation. Kontrollera om klientorganisationer själva konfigurerar federationen eller om processen kräver manuell konfiguration och underhåll av ditt team.

• Definiera vilka federationsprotokoll som din lösning stöder.

• Upprätta processer som förhindrar att federationsfelkonfigurationer beviljar åtkomst till oavsiktliga klienter.

• Planera om en enskild klientorganisations IdP måste federeras till mer än en klientorganisation i din lösning. Om kunderna till exempel har både en test- och en produktionsklientorganisation skulle samma IdP behöva federeras med varje klientorganisation.

Auktoriseringsmodeller

Bestäm vilken auktoriseringsmodell som passar bäst för din lösning. Överväg följande vanliga auktoriseringsmetoder:

• Rollbaserad auktorisering: Användare tilldelas till roller. Vissa funktioner i programmet är begränsade till specifika roller. En användare i administratörsrollen kan till exempel utföra vilken åtgärd som helst, medan en användare i en lägre roll kan ha en delmängd behörigheter i hela systemet.

• Resursbaserad auktorisering: Lösningen innehåller en uppsättning distinkta resurser som var och en har en egen uppsättning behörigheter. En specifik användare kan vara administratör för en resurs och har ingen åtkomst till en annan resurs.

De här modellerna är distinkta och den metod som du väljer påverkar implementeringen och komplexiteten i de auktoriseringsprinciper som du kan implementera.

Rättigheter och licensiering

I vissa lösningar kan du använda licensiering per användare som en del av din kommersiella prismodell. I det här scenariot anger du olika nivåer av användarlicenser som har olika funktioner. Användare med en licens kan till exempel tillåtas använda en delmängd av programmets funktioner. De funktioner som specifika användare får åtkomst till, baserat på deras licenser, kallas ibland för berättigande.

Programkoden eller ett dedikerat rättighetssystem spårar vanligtvis och tillämpar rättigheter i stället för identitetssystemet. Den här processen liknar auktorisering men sker utanför identitetshanteringsskiktet.

Identitetsskala och autentiseringsvolym

I takt med att lösningar för flera klienter växer ökar antalet användare och inloggningsbegäranden som lösningen behöver bearbeta. Överväg följande faktorer:

• Utvärdera om användarkatalogen skalar för att stödja det antal användare som krävs.

• Utvärdera om autentiseringsprocessen hanterar det förväntade antalet inloggningar och registreringar.

• Avgör om det finns toppar som autentiseringssystemet inte kan hantera. Klockan 09.00 stillahavstid kan till exempel alla i västra USA börja arbeta och logga in på din lösning, vilket skapar en topp i inloggningsbegäranden. Dessa scenarier kallas ibland inloggningsstormar.

• Avgör om hög belastning i delar av lösningen påverkar autentiseringsprocessens prestanda. Om autentisering till exempel kräver anrop till ett API på programnivå kan en ökning av autentiseringsbegäranden påverka den övergripande systemprestandan.

• Definiera hur din lösning fungerar om IdP:t blir otillgängligt. Överväg om en tjänst för säkerhetskopieringsautentisering ska ingå för att upprätthålla affärskontinuitet.

Deltagare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudsakliga författare:

• John Downs | Principal Software Engineer, Azure Patterns &Practices
• Daniel Scott-Raynsford | Partnerteknikstrateg
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Övriga medarbetare:

• Jelle Druyts | Huvudkundtekniker, FastTrack för Azure
• Landon Pierce | Senior kundtekniker
• Sander van den Hoven | Senior Partner Technology Strategist
• Nick Ward - Sverige | Senior molnlösningsarkitekt

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Relaterad resurs

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