Dela via

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

  • Artikel

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

  • Verifiera vem en användare är (autentisering).
  • Framtvinga användarens behörigheter inom omfånget för en klientorganisation (auktorisering).

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

Varning

Autentiserings- och auktoriseringstjänster, inom program med flera klienter och SaaS, tillhandahålls vanligtvis av en identitetsprovider från tredje part (IdP). En identitetsprovider är vanligtvis en integrerad del av en IDaaS-plattform (identitet som en tjänst).

Att skapa en egen IdP är komplext, dyrt och svårt att bygga på ett säkert sätt. Att skapa en egen identitetsprovider är ett antimönster. Vi rekommenderar det inte.

Innan du definierar en identitetsstrategi för flera klientorganisationer bör du först överväga de övergripande identitetskraven för din tjänst, inklusive följande krav:

  • Kommer en användare eller arbetsbelastningsidentitet att användas för att komma åt ett enda program eller flera program i en produktfamilj? En detaljhandelsproduktfamilj kan till exempel ha både ett kassaprogram och ett inventeringshanteringsprogram som delar samma identitetslösning.
  • Planerar du att implementera modern autentisering och auktorisering, till exempel OAuth2 och OpenID Connect?
  • Tillhandahåller din lösning endast autentisering till dina användargränssnittsbaserade program? Eller ger du även API-åtkomst till dina klienter och tredje part?
  • Måste klientorganisationer federera till sin egen IdP och måste flera olika identitetsprovidrar stödjas för varje klientorganisation? Du kan till exempel ha klienter med Microsoft Entra-ID, Auth0 och Active Directory Federation Services (AD FS) (ADFS), där var och en vill federera med din lösning. Du måste också förstå vilka federationsprotokoll för klientorganisationens IP-adresser som du kommer att stödja, eftersom protokollen påverkar kraven för din egen IdP.
  • Finns det särskilda efterlevnadskrav som de behöver uppfylla, till exempel GDPR?
  • Kräver dina klienter att deras identitetsinformation finns inom en specifik geografisk region?
  • Kräver användare av din lösning åtkomst till data från en klientorganisation eller från flera klienter i ditt program? Behöver de möjlighet att snabbt växla mellan klienter eller visa konsoliderad information från flera klienter? Användare som har loggat in på Azure Portal kan till exempel enkelt växla mellan olika Microsoft Entra ID-kataloger och prenumerationer som de har åtkomst till.

När du har fastställt dina krav på hög nivå kan du börja planera mer specifik information och krav, till exempel användarkatalogkällor och registrerings-/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 innehålla referenser till externa identiteter som lagras i en annan identitetsproviders katalog.

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:

  • Lokal identitetsprovider. Med en lokal identitetsprovider kan användarna 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 identitetsprovider. En social identitetsprovider gör det möjligt för användare att använda en identitet som de har på ett socialt nätverk eller någon annan offentlig identitetsprovider, till exempel Facebook, Google eller ett personligt Microsoft-konto.
  • Använd klientorganisationens Microsoft Entra ID-katalog. Klientorganisationer kanske 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 klients identitetsprovider. Klienter kan 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) och gör det 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 identitetsprovidrar. Du kan till exempel behöva stödja lokala identiteter, sociala identiteter och federerade identiteter, allt inom en enda klientorganisation. Det här kravet är vanligt när företag använder en lösning som är både för sina egna anställda och för entreprenörer. De kan använda federation för sina egna anställdas åtkomst till lösningen, samtidigt som de ger åtkomst till leverantörer eller gästanvändare, som inte har något konto i den federerade IdP:n.

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 krävs av dina klienter.
  • Information som krävs för att autentisera dina användare på ett säkert sätt, inklusive information som krävs för att tillhandahålla multifaktorautentisering (MFA).
  • Klientspecifik information, till exempel klientroller och behörigheter. Den här informationen används för auktorisering.

Varning

Vi rekommenderar inte att du skapar autentiseringsprocesser själv. Moderna IP-adresser tillhandahåller dessa autentiseringstjänster till ditt program, och de innehåller även andra viktiga funktioner, till exempel MFA och villkorlig åtkomst. Att skapa en egen identitetsprovider är ett antimönster. Vi rekommenderar det inte.

Ö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ändarautentiseringsuppgifterna i IdP-katalogen och lagra auktoriseringsinformationen på programnivån, tillsammans med klientinformationen.

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

Det är vanligt att lösningar för flera klienter tillåter att en användar- eller arbetsbelastningsidentitet får åtkomst till programmet och data för flera klientorganisationer. Överväg om den här metoden krävs för din lösning. Om så är fallet bör du överväga följande frågor:

  • Ska du skapa en enskild användaridentitet för varje person eller skapa separata identiteter för varje kombination av klient-användare?
    • Det är bäst att använda en enda identitet för varje person, där det är möjligt. Det blir svårt att hantera flera användarkonton, både för dig som lösningsleverantör och även för dina användare. Dessutom förlitar sig många av de intelligenta hotskydd som erbjuds av en modern IdP på att varje person har ett enda användarkonto.
    • I vissa situationer kan det dock vara nödvändigt för en användare att ha flera distinkta identiteter. 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 krav på regelbaserad eller geografisk datalagring kan de kräva att en person har flera identiteter så att de kan följa regler eller lagar.
  • Om du använder identiteter per klientorganisation bör du undvika att lagra autentiseringsuppgifter flera gånger. 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

Överväg hur användare ska mappas till en klientorganisation. Under registreringsprocessen kan du till exempel använda en unik inbjudningskod som de anger första gången de får åtkomst till en klientorganisation. I vissa lösningar kan du använda domännamnet för användarnas e-postadresser för registrering som ett sätt att identifiera den klientorganisation som de tillhör. Eller så kan du använda ett annat attribut för användarens identitetspost för att mappa användaren till en klientorganisation. Du bör sedan lagra mappningen baserat på de underliggande oföränderliga unika identifierarna för både klientorganisationen och användaren.

Om din lösning är utformad så att en enskild användare bara kommer att komma åt data för en enda klientorganisation bör du överväga följande beslut:

  • Hur identifierar IdP vilken klientorganisation en användare har åtkomst till?
  • Hur kommunicerar IdP:t klientidentifieraren till programmet? Vanligtvis läggs ett klientidentifieraranspråk till i token.

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

  • Hur identifierar och beviljar din lösning behörighet till en användare som har åtkomst till flera klienter? Kan en användare till exempel vara administratör i en utbildningsklientorganisation och ha skrivskyddad åtkomst till en produktionsklient? Eller kan du ha separata klienter för olika avdelningar i en organisation, men du behöver ha konsekventa användaridentiteter för alla klienter?
  • Hur växlar en användare mellan klienter?
  • Hur anger en arbetsbelastningsidentitet den klientorganisation som den behöver åtkomst till om du använder arbetsbelastningsidentiteter?
  • Finns det klientspecifik information som lagras i användarens identitetspost som kan läcka information mellan klienter? Anta till exempel att en användare har registrerat sig med en social identitet och sedan beviljats åtkomst till två klienter. Klientorganisation A berikade användarens identitet med mer information. Ska klient B ha åtkomst till den berikade informationen?

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

Vissa klienter kan behöva tillåta användare att registrera sig för en identitet i din lösning. Självbetjäningsregistrering kan krävas om du inte behöver federation med en klientorganisations identitetsprovider. Om det behövs en självregistreringsprocess bör du överväga följande frågor:

  • Vilka identitetskällor tillåts användare att registrera sig från? Kan en användare till exempel skapa en lokal identitet och även använda en social identitetsprovider?
  • Kommer endast specifika e-postdomäner att tillåtas om endast lokala identiteter tillåts? Kan till exempel en klientorganisation ange att endast användare som har en @contoso.com e-postadress får registrera sig?
  • Vilket är användarens huvudnamn (UPN) som ska användas för att unikt identifiera varje lokal identitet under inloggningsprocessen? Till exempel är en e-postadress, användarnamn, telefonnummer och belöningskortnummer alla vanliga alternativ för UPN. UPN kan dock ändras över tid. När du refererar till identiteten i programmets auktoriseringsregler eller granskningsloggar är det en bra idé att använda den underliggande oföränderliga unika identifieraren för identiteten. Microsoft Entra ID tillhandahåller ett objekt-ID (OID), som är en oföränderlig identifierare.
  • Kommer en användare att behöva verifiera sitt UPN? Hur kontrollerar du att informationen är korrekt om användarens e-postadress eller telefonnummer används som ett UPN?
  • Behöver klientadministratörer godkänna registreringar?
  • Kräver klientorganisationer en klientspecifik registreringsupplevelse eller URL? Behöver dina klienter till exempel en varumärkesanpassad registreringsupplevelse när användarna registrerar sig? Kräver dina klienter möjligheten att fånga upp en registreringsbegäran och utföra extra validering innan den fortsätter?

Klientåtkomst för självregistreringsanvändare

När användare får registrera sig för en identitet måste det vanligtvis finnas en process för att de ska beviljas åtkomst till en klientorganisation. Registreringsflödet kan innehålla en åtkomstbeviljande process, eller så kan det automatiseras baserat på information om användarna, till exempel deras e-postadresser. Det är viktigt att planera för den här processen och överväga följande frågor:

  • Hur avgör registreringsflödet att en användare ska beviljas åtkomst till en specifik klientorganisation?
  • Om användarna inte längre ska ha åtkomst till en klientorganisation, kommer din lösning automatiskt att återkalla deras åtkomst? När användarna till exempel lämnar en organisation måste det finnas en manuell eller automatiserad process som tar bort deras åtkomst från klientorganisationen.
  • Behöver du tillhandahålla ett sätt för klientorganisationer att granska de användare som har åtkomst till sina klienter och deras 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 kontoregistrering och off-boarding. Öppna protokoll, till exempel System for Cross-domain Identity Management (SCIM) ger en branschstandardmetod för automatisering. Den här automatiserade processen omfattar vanligtvis inte bara skapande och borttagning av identitetsposter, utan även hantering av klientbehörigheter. Tänk på följande frågor när du implementerar automatiserad livscykelhantering för konton i en lösning med flera klientorganisationer:

  • Behöver dina kunder konfigurera och hantera en automatiserad livscykelprocess per 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.
  • Behöver du implementera SCIM, eller kan du tillhandahålla klientorganisationsfederation i stället, för att hålla sanningskällan för användare under kontroll av klientorganisationen i stället för att hantera lokala användare?

Användarautentiseringsprocess

När en användare loggar in på ett program med flera klientorganisationer autentiserar ditt identitetssystem användaren. Du bör överväga följande frågor när du planerar autentiseringsprocessen:

  • Behöver dina klienter konfigurera sina egna MFA-principer (multifaktorautentisering) ? 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.
  • Behöver dina klienter konfigurera sina egna regler för villkorlig åtkomst? Olika klienter kan till exempel behöva blockera inloggningsförsök från specifika geografiska regioner.
  • Behöver dina klienter anpassa inloggningsprocessen för varje klientorganisation? Behöver du till exempel visa en kunds logotyp? Eller behöver information om varje användare extraheras från ett annat system, till exempel ett belöningsnummer, och returneras till identitetsprovidern för att lägga till i användarprofilen?
  • Behöver användarna 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.
  • Behöver användarna få åtkomst till API:erna för din lösning? Till exempel kan användare eller program från tredje part behöva anropa dina API:er direkt för att utöka din lösning, utan ett användargränssnitt för att tillhandahålla ett autentiseringsflöde.

Arbetsbelastningsidentiteter

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 tillhandahålls av din lösning, så att de kan automatisera vissa av sina hanteringsuppgifter.

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 förväntar sig att kunna aktivera arbetsbelastningsidentitetsåtkomst till din lösning för flera klienter bör du överväga följande frågor:

  • Hur skapas och hanteras arbetsbelastningsidentiteter i varje klientorganisation?
  • Hur kommer identitetsbegäranden för arbetsbelastningar att begränsas till klientorganisationen?
  • Behöver du begränsa antalet arbetsbelastningsidentiteter som skapas av varje klientorganisation?
  • Behöver du tillhandahålla kontroller för villkorlig åtkomst för arbetsbelastningsidentiteter för varje klientorganisation? En klientorganisation kanske till exempel vill begränsa en arbetsbelastningsidentitet från att autentiseras utanför en viss region.
  • Vilka säkerhetskontroller ska du tillhandahålla klientorganisationer för att säkerställa att arbetsbelastningsidentiteter hålls säkra? Automatisk nyckelrullning, nyckelförfallodatum, certifikatets giltighetstid och övervakning av inloggningsrisker är till exempel alla metoder för att minska risken, där en arbetsbelastningsidentitet kan missbrukas.

Federera med en identitetsprovider för enkel inloggning (SSO)

Klienter, som redan har egna användarkataloger, kanske vill att din lösning ska federera 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 funktioner för enkel inloggning (SSO).

Om du förväntar dig att klienterna ska federeras med din lösning bör du överväga följande frågor:

  • Vad är processen för att konfigurera federationen för en klientorganisation? Kan klientorganisationer själva konfigurera federation, eller kräver processen manuell konfiguration och underhåll av ditt team?
  • Vilka federationsprotokoll stöder du?
  • Vilka processer finns på plats för att säkerställa att federationen inte kan konfigureras fel för att ge åtkomst till en annan klientorganisation?
  • Måste en enskild klients identitetsprovider federeras till mer än en klientorganisation i din lösning? Om kunderna till exempel har både en utbildnings- och produktionsklientorganisation kan de behöva federera samma identitetsprovider till båda klienterna.

Auktoriseringsmodeller

Bestäm vilken auktoriseringsmodell som passar bäst för din lösning. Två vanliga auktoriseringsmetoder är:

  • 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.

Dessa modeller är distinkta och den metod 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. Du skulle tillhandahålla olika nivåer av användarlicenser med 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.

Även om spårning och framtvingande av rättigheter liknar auktorisering hanteras det vanligtvis av programkoden eller av ett dedikerat rättighetssystem, i stället för att hanteras av identitetssystemet.

Identitetsskala och autentiseringsvolym

I takt med att lösningar för flera klienter växer ökar antalet användare och inloggningsbegäranden som behöver bearbetas av lösningen. Du bör överväga följande frågor:

  • Kommer användarkatalogen att skalas till det antal användare som krävs?
  • Kommer autentiseringsprocessen att hantera det förväntade antalet inloggningar och registreringar?
  • Kommer det att finnas toppar som autentiseringssystemet inte kan hantera? Klockan 09.00 kan till exempel alla i den västra USA regionen börja arbeta och logga in på din lösning, vilket orsakar en topp i inloggningsbegäranden. Dessa situationer kallas ibland inloggningsstormar.
  • Kan hög belastning i andra delar av lösningen påverka autentiseringsprocessens prestanda? Om din autentiseringsprocess till exempel kräver att ett API på programnivå anropas, kommer ett stort antal autentiseringsbegäranden att orsaka problem för resten av lösningen?
  • Vad händer om din IdP blir otillgänglig? Finns det en tjänst för säkerhetskopieringsautentisering som kan ta över för att tillhandahålla affärskontinuitet, medan IdP:t inte är tillgänglig?

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 arkitekturmetoder för identitet i lösningar med flera klientorganisationer.