Architectuuroverwegingen voor identiteit in een multitenant-oplossing

Identiteit is een belangrijk aspect van elke multitenant-oplossing. De identiteitsonderdelen van uw toepassing zijn verantwoordelijk voor de volgende taken:

• De identiteit van een gebruiker verifiëren, ook wel verificatie genoemd

• De machtigingen van een gebruiker afdwingen binnen het bereik van een tenant, ook wel autorisatie genoemd

Uw klanten willen mogelijk ook externe toepassingen autoriseren voor toegang tot hun gegevens of integreren met uw oplossing. De identiteit van een gebruiker bepaalt welke informatie een gebruiker of service kan openen. Het is belangrijk dat u rekening houdt met uw identiteitsvereisten om toepassingen en gegevens tussen huurders te isoleren.

Voordat u een strategie voor meerdere tenants-identiteit definieert, moet u eerst rekening houden met de volgende identiteitsvereisten op hoog niveau voor uw service:

• Bepaal of gebruikers of workloadidentiteiten toegang hebben tot één toepassing of meerdere toepassingen binnen een productfamilie. Sommige productfamilies kunnen verschillende toepassingen bevatten die dezelfde identiteitsinfrastructuur delen, zoals point-of-sale-systemen en voorraadbeheerplatforms.

• Overweeg of uw oplossing moderne verificatie- en autorisatiestandaarden implementeert, zoals OAuth2 en OpenID Connect.

• Evalueer of verificatie is beperkt tot toepassingen op basis van de gebruikersinterface of dat API-toegang ook van toepassing is op tenants en systemen van derden.

• Bepaal of huurders moeten federeren met hun eigen IdP's en of er meerdere IdP's ondersteund moeten worden voor elke huurder. U hebt bijvoorbeeld tenants met Microsoft Entra ID, Auth0 en Active Directory Federation Services, waarbij elke tenant federatief is met uw oplossing. Bepaal welke federatieprotocollen hun IdPs gebruiken, omdat deze protocollen bepalen wat uw IdP moet ondersteunen.

• Bekijk alle toepasselijke nalevingsvereisten waaraan ze moeten voldoen, zoals de Algemene Verordening Gegevensbescherming (AVG) die uw identiteitsstrategie vormen.

• Bepaal of voor tenants identiteitsgegevens moeten worden opgeslagen in specifieke geografische regio's om te voldoen aan wettelijke, nalevings- of operationele behoeften.

• Beoordeel of gebruikers toegang hebben tot gegevens van meerdere tenants binnen de toepassing. Als ze dat doen, moet u mogelijk naadloze tenantwisselingen ondersteunen of geconsolideerde weergaven bieden voor specifieke gebruikers. Gebruikers die zich bijvoorbeeld aanmelden bij Azure Portal, kunnen eenvoudig schakelen tussen verschillende Microsoft Entra ID-directory's en abonnementen waartoe ze toegang hebben.

Wanneer u uw algemene vereisten instelt, kunt u meer specifieke details en vereisten plannen, zoals gebruikersdirectorybronnen en registratie- en aanmeldingsstromen.

Identiteitsdirectory

Voor een multitenant-oplossing om een gebruiker of service te verifiëren en autoriseren, moet deze een plaats hebben om identiteitsgegevens op te slaan. Een directory kan gezaghebbende records voor elke identiteit bevatten. Het kan ook verwijzingen bevatten naar externe identiteiten die zijn opgeslagen in de map van een andere IdP.

Wanneer u een identiteitssysteem ontwerpt voor uw multitenant-oplossing, moet u overwegen welke van de volgende typen IdP uw tenants en klanten nodig hebben:

• Lokale IdP: Met een lokale IdP kunnen gebruikers zich aanmelden voor de service. Gebruikers geven een gebruikersnaam, een e-mailadres of een id op, zoals een rewards-kaartnummer. Ze geven ook inloggegevens op, zoals een wachtwoord. De IdP slaat zowel de gebruikers-id als de referenties op.

• Sociale idP: Met een sociale IdP kunnen gebruikers een identiteit gebruiken die ze hebben op een sociaal netwerk of een andere openbare IdP, zoals Facebook, Google of een persoonlijk Microsoft-account. Sociale ID's worden vaak gebruikt in SaaS-oplossingen (business-to-consumer) (B2C).

• De Microsoft Entra ID-directory van de tenant: In veel Business-to-Business (B2B) SaaS-oplossingen hebben tenants mogelijk al hun eigen Microsoft Entra ID-directory en willen ze mogelijk dat uw oplossing hun directory als IdP gebruikt voor het verkrijgen van toegang tot uw oplossing. Deze aanpak is mogelijk wanneer uw oplossing is gebouwd als een Multitenant Microsoft Entra-toepassing.

• Federatie met de IdP van een tenant: In sommige B2B SaaS-oplossingen hebben tenants mogelijk hun eigen IdP, met uitzondering van Microsoft Entra-id, en willen ze mogelijk dat uw oplossing ermee kan worden gefedereerd. Federatie schakelt eenmalige aanmelding (SSO) in. Het stelt tenants ook in staat om de levenscyclus en het beveiligingsbeleid van hun gebruikers onafhankelijk van uw oplossing te beheren.

U moet overwegen of uw tenants meerdere IdP's moeten ondersteunen. Een enkele tenant moet bijvoorbeeld ondersteuning bieden voor lokale identiteiten, sociale identiteiten en federatieve identiteiten. Deze vereiste is gebruikelijk wanneer bedrijven een oplossing gebruiken die is bedoeld voor zowel hun werknemers als aannemers. Ze kunnen federatie gebruiken om werknemers toegang te verlenen, terwijl ze ook toegang verlenen aan contractanten of gebruikers die geen accounts hebben in de federatieve IdP.

Verificatie- en tenantautorisatiegegevens opslaan

In een multitenant-oplossing moet u overwegen waar verschillende typen identiteitsgegevens moeten worden opgeslagen, waaronder de volgende typen:

• Details over gebruikers- en serviceaccounts, inclusief hun namen en andere informatie die uw tenants nodig hebben.

• Informatie die nodig is om uw gebruikers veilig te verifiëren, inclusief informatie voor meervoudige verificatie (MFA).

• Tenantspecifieke informatie, zoals tenantrollen en machtigingen, voor autorisatie.

Houd rekening met de volgende opties voor het opslaan van identiteitsgegevens:

• Sla alle identiteits- en autorisatiegegevens op in de IdP-map en deel deze tussen meerdere tenants.

• Sla gebruikersreferenties op in de IdP-map. Sla autorisatiegegevens op in de toepassingslaag, naast tenantgegevens.

Het aantal identiteiten voor een gebruiker bepalen

Met multitenant-oplossingen kan een gebruikers- of workloadidentiteit vaak toegang krijgen tot toepassingsresources en -gegevens in meerdere tenants. Houd rekening met de volgende factoren wanneer deze aanpak is vereist:

• Bepaal of u één gebruikersidentiteit wilt maken voor elke persoon of afzonderlijke identiteiten wilt maken voor elke combinatie van tenantgebruikers.

  • Gebruik indien mogelijk één identiteit voor elke persoon. Het vereenvoudigt accountbeheer voor zowel de oplossingsprovider als de gebruikers. Veel van de intelligente bedreigingsbeveiligingen die moderne ID's bieden, zijn ook afhankelijk van elke persoon met één gebruikersaccount.

  • Gebruik in sommige scenario's meerdere afzonderlijke identiteiten. Als mensen uw systeem bijvoorbeeld zowel gebruiken voor werk- als persoonlijke doeleinden, willen ze mogelijk hun gebruikersaccounts scheiden. Of als uw tenants strikte wettelijke of geografische vereisten voor gegevensopslag hebben, moeten ze mogelijk een persoon meerdere identiteiten hebben, zodat ze aan regelgeving of wetten kunnen voldoen.

• Vermijd het meerdere keren opslaan van inloggegevens als u per-tenant identiteiten gebruikt. Gebruikers moeten hun referenties hebben opgeslagen op één identiteit en u moet functies zoals gastidentiteiten gebruiken om te verwijzen naar dezelfde gebruikersreferenties uit de identiteitsrecords van meerdere tenants.

Gebruikers toegang verlenen tot tenantgegevens

Overweeg hoe u gebruikers wilt toewijzen aan een tenant. Tijdens het registratieproces kunt u bijvoorbeeld een unieke uitnodigingscode opgeven die gebruikers kunnen invoeren wanneer ze voor het eerst toegang hebben tot een tenant. In sommige oplossingen kan de domeinnaam van het aanmeldings-e-mailadres van de gebruiker de bijbehorende tenant identificeren. U kunt ook een ander kenmerk uit de identiteitsrecord van de gebruiker gebruiken om de tenanttoewijzing te bepalen. Deze koppeling moet vervolgens worden opgeslagen op basis van onveranderbare, unieke id's voor zowel de tenant als de gebruiker.

Als uw oplossing elke gebruiker beperkt tot toegang tot gegevens voor één tenant, moet u de volgende beslissingen nemen:

• Bepaal hoe de IdP detecteert welke tenant een gebruiker benadert.

• Leg uit hoe de IdP de tenant-id communiceert met de toepassing. Normaal gesproken wordt een tenant-identificatieclaim toegevoegd aan het token.

Als één gebruiker toegang moet krijgen tot meerdere tenants, moet u de volgende beslissingen nemen:

• De oplossing moet logica ondersteunen voor het identificeren van gebruikers en het verlenen van de juiste machtigingen voor tenants. Een gebruiker kan bijvoorbeeld beheerdersrechten hebben in de ene tenant, maar beperkte toegang in een andere tenant. Stel dat een gebruiker zich heeft geregistreerd met een sociale identiteit en vervolgens toegang heeft gekregen tot twee tenants. Tenant A heeft de identiteit van de gebruiker verrijkt met meer informatie. Moet tenant B toegang hebben tot de verrijkte informatie?

• Met een duidelijk mechanisme kunnen gebruikers schakelen tussen tenants. Deze aanpak zorgt voor een soepele gebruikerservaring en voorkomt onbedoelde toegang tussen tenants.

• Als u workload-identiteiten gebruikt, moet u opgeven welke tenant ze proberen toegang te krijgen tot. Deze vereiste omvat mogelijk het insluiten van tenantspecifieke context in verificatieaanvragen.

• Overweeg of tenantspecifieke informatie die is opgeslagen in de identiteitsrecord van een gebruiker onbedoeld kan lekken tussen tenants. Als een gebruiker zich bijvoorbeeld aanmeldt met een sociale identiteit en toegang krijgt tot twee tenants, en Tenant A het gebruikersprofiel verrijkt, bepaalt u of Tenant B toegang moet hebben tot die verrijkte informatie.

Registratieproces van gebruikers voor lokale identiteiten of sociale identiteiten

Sommige tenants moeten mogelijk toestaan dat gebruikers zich registreren voor een identiteit in uw oplossing. Selfserviceregistratie is mogelijk vereist als u geen federatie met de IdP van een tenant nodig hebt. Als u een zelfregistratieproces nodig hebt, moet u rekening houden met de volgende factoren:

• Definieer bij welke identiteitsbronnen gebruikers zich mogen registreren. Bepaal bijvoorbeeld of gebruikers een lokale identiteit kunnen maken en ook een sociale IdP kunnen gebruiken.

• Geef op of uw oplossing alleen specifieke e-maildomeinen toestaat als lokale identiteiten worden gebruikt. Bepaal bijvoorbeeld of een tenant registraties kan beperken tot gebruikers met een @contoso.com e-mailadres.

• De UPN (User Principal Name) die wordt gebruikt voor het identificeren van lokale identiteiten, moet duidelijk tot stand worden gebracht. Veelvoorkomende UPN's zijn e-mailadressen, gebruikersnamen, telefoonnummers of lidmaatschaps-id's. Omdat UPN's kunnen worden gewijzigd, is het raadzaam om te verwijzen naar de onderliggende onveranderbare unieke id voor autorisatie en controle. Een voorbeeld is de object-id (OID) in Microsoft Entra-id.

• Verificatie van UPN's kan vereist zijn om de nauwkeurigheid ervan te waarborgen. Dit proces kan het eigendom van een e-mailadres of telefoonnummer valideren voordat toegang wordt verleend.

• Voor sommige oplossingen moeten tenantbeheerders mogelijk aanmeldingen van gebruikers goedkeuren. Met dit goedkeuringsproces kunt u beheer beheren over wie lid wordt van een tenant.

• Bepaal of tenants een tenantspecifieke aanmeldingservaring of URL vereisen. Bepaal bijvoorbeeld of uw klanten een gepersonaliseerde registratiesessie nodig hebben bij registratie, of de mogelijkheid om een aanmeldingsverzoek te onderscheppen en vooraf extra validatie uit te voeren voordat deze doorgezet wordt.

Tenanttoegang voor zelfregistratiegebruikers

Als gebruikers zich kunnen aanmelden voor een identiteit, definieert u een proces om hen toegang te verlenen tot een tenant. De registratiestroom kan bestaan uit een handmatig toegangsproces of een geautomatiseerd proces op basis van de informatie over de gebruikers, zoals hun e-mailadressen. Het is belangrijk om dit proces te plannen en rekening te houden met de volgende factoren:

• Definieer hoe de registratiestroom bepaalt dat een gebruiker toegang krijgt tot een specifieke tenant.

• Geef aan of uw oplossing gebruikerstoegang tot een tenant automatisch intrekt, indien van toepassing. Wanneer gebruikers bijvoorbeeld een organisatie verlaten, moet er een handmatig of geautomatiseerd proces zijn om hun toegang te verwijderen.

• Bied een gebruikerscontrolemogelijkheid zodat tenants kunnen controleren welke gebruikers toegang hebben tot hun omgeving en inzicht hebben in hun toegewezen machtigingen.

Geautomatiseerd accountlevenscyclusbeheer

Een veelvoorkomende vereiste voor zakelijke of zakelijke klanten van een oplossing is een set functies waarmee ze onboarding en offboarding van accounts kunnen automatiseren. Open protocollen, zoals System for Cross-Domain Identity Management (SCIM), bieden een industriestandaard benadering voor automatisering. Dit geautomatiseerde proces omvat meestal het maken en verwijderen van identiteitsrecords en het beheer van tenantmachtigingen. Houd rekening met de volgende factoren wanneer u geautomatiseerd accountlevenscyclusbeheer implementeert in een multitenant-oplossing:

• Bepaal of uw klanten een geautomatiseerd levenscyclusproces voor elke tenant moeten configureren en beheren. Wanneer een gebruiker bijvoorbeeld wordt geïntroduceerd, moet u mogelijk de identiteit creëren binnen meerdere gebruikersomgevingen in uw toepassing, waarbij elke omgeving een andere set machtigingen heeft.

• Bepaal of u SCIM of federatie van aanbiedingen moet implementeren. Met federatie kunnen tenants de controle over gebruikersbeheer behouden door de bron van waarheid binnen hun eigen systemen te bewaren in plaats van lokale gebruikers in uw oplossing te beheren.

Gebruikersverificatieproces

Wanneer een gebruiker zich aanmeldt bij een toepassing met meerdere tenants, verifieert uw identiteitssysteem de gebruiker. Houd rekening met de volgende factoren wanneer u uw verificatieproces plant:

• Voor sommige tenants is mogelijk de mogelijkheid vereist om hun eigen MFA-beleid te configureren. Als uw tenants zich bijvoorbeeld in de financiële dienstverlening bevinden, moeten ze strikte MFA-beleidsregels implementeren, terwijl een kleine onlinewinkel mogelijk niet dezelfde vereisten heeft.

• De optie voor het definiëren van aangepaste regels voor voorwaardelijke toegang is mogelijk belangrijk voor tenants. Verschillende tenants moeten bijvoorbeeld aanmeldingspogingen van specifieke geografische regio's blokkeren.

• Bepaal of tenants het aanmeldingsproces afzonderlijk moeten aanpassen. Uw oplossing moet bijvoorbeeld het logo van een klant weergeven. Het kan ook nodig zijn om gebruikersgegevens, zoals een beloningsnummer, van een ander systeem op te halen en terug te keren naar de IdP om het gebruikersprofiel te verrijken.

• Sommige gebruikers moeten mogelijk andere gebruikers imiteren. Een ondersteuningsteamlid kan bijvoorbeeld een probleem onderzoeken dat een andere gebruiker heeft door zijn gebruikersaccount te imiteren zonder zich te hoeven verifiëren als de gebruiker.

• API-toegang is mogelijk vereist voor sommige gebruikers of externe toepassingen. Deze scenario's kunnen omvatten het rechtstreeks aanroepen van de API's van de oplossing, waardoor standaardgebruikersverificatiestromen worden overgeslagen.

Workloadidentiteiten

In de meeste oplossingen vertegenwoordigt een identiteit vaak een gebruiker. Bij sommige systemen met meerdere tenants kunnen ook workloadidentiteiten worden gebruikt door services en toepassingen om toegang te krijgen tot uw toepassingsresources. Uw tenants moeten bijvoorbeeld toegang hebben tot een API die uw oplossing biedt, zodat ze hun beheertaken kunnen automatiseren.

Microsoft Entra ondersteunt workloadidentiteiten, en andere IdPs ondersteunen deze meestal ook.

Workloadidentiteiten zijn vergelijkbaar met gebruikersidentiteiten, maar vereisen meestal verschillende verificatiemethoden, zoals sleutels of certificaten. Workloadidentiteiten maken geen gebruik van MFA. In plaats daarvan zijn voor workloadidentiteiten meestal andere beveiligingscontroles vereist, zoals het regelmatig roteren van sleutels en het laten verlopen van certificaten.

Als uw tenants workloadidentiteitstoegang tot uw multitenant-oplossing kunnen inschakelen, moet u rekening houden met de volgende factoren:

• Bepaal hoe de workloadidentiteiten in elke tenant worden gemaakt en beheerd.

• Bepaal hoe aanvragen voor workloadidentiteit worden afgestemd op de tenant.

• Evalueer of u het aantal workloadidentiteiten wilt beperken dat door elke tenant wordt gemaakt.

• Bepaal of controles voor voorwaardelijke toegang vereist zijn voor workload-identiteiten in elke tenant. Een tenant kan bijvoorbeeld een workloadidentiteit beperken voor verificatie van buiten een specifieke regio.

• Bepaal welke beveiligingsmaatregelen u aan tenants levert om ervoor te zorgen dat workloadidentiteiten veilig blijven. Geautomatiseerde sleutelverloop, verlooptijd van sleutels, certificaatverloop en aanmeldingsrisicobewaking helpen bijvoorbeeld het risico op misbruik van workloadidentiteiten te verminderen.

Federeer met een IdP voor Single Sign-On (SSO)

Tenants die al hun eigen gebruikersdirectory's hebben, willen mogelijk dat uw oplossing met hun directory's integreert. Met federatie kan uw oplossing de identiteiten in hun directory gebruiken in plaats van een andere map met afzonderlijke identiteiten te beheren.

Federatie is vooral belangrijk wanneer sommige tenants hun eigen identiteitsbeleid willen opgeven of SSO-ervaringen willen inschakelen.

Als u verwacht dat tenants federeren met uw oplossing, moet u rekening houden met de volgende factoren:

• Overweeg het proces voor het configureren van de federatie voor een tenant. Bepaal of tenants federatie zelf configureren of als voor het proces handmatige configuratie en onderhoud door uw team is vereist.

• Definieer welke federatieprotocollen uw oplossing ondersteunt.

• Stel processen in die voorkomen dat onjuiste configuraties van federatie toegang verlenen tot onbedoelde tenants.

• Plan of de IdP van één tenant moet worden gefedereerd naar meer dan één tenant in uw oplossing. Als klanten bijvoorbeeld zowel een training als een productietenant hebben, moeten ze mogelijk dezelfde IdP met elke tenant federeren.

Autorisatiemodellen

Beslis over het autorisatiemodel dat het meest zinvol is voor uw oplossing. Houd rekening met de volgende algemene autorisatiemethoden:

• Autorisatie op basis van rollen: Gebruikers worden toegewezen aan rollen. Sommige functies van de toepassing zijn beperkt tot specifieke rollen. Een gebruiker in de beheerdersrol kan bijvoorbeeld elke actie uitvoeren, terwijl een gebruiker in een lagere rol mogelijk een subset machtigingen heeft in het hele systeem.

• Autorisatie op basis van resources: Uw oplossing biedt een set afzonderlijke resources, die elk een eigen set machtigingen hebben. Een specifieke gebruiker kan een beheerder van één resource zijn en geen toegang hebben tot een andere resource.

Deze modellen zijn verschillend en de aanpak die u selecteert, is van invloed op uw implementatie en de complexiteit van het autorisatiebeleid dat u kunt implementeren.

Rechten en licenties

In sommige oplossingen kunt u licenties per gebruiker gebruiken als onderdeel van uw commerciële prijsmodel. In dit scenario biedt u verschillende lagen gebruikerslicenties met verschillende mogelijkheden. Gebruikers met één licentie kunnen bijvoorbeeld een subset van de functies van de toepassing gebruiken. De mogelijkheden waartoe specifieke gebruikers toegang hebben, op basis van hun licenties, worden ook wel rechten genoemd.

U wordt aangeraden rechten in uw toepassingscode of een toegewezen rechtensysteem bij te houden en af te dwingen, in plaats van te vertrouwen op het identiteitssysteem. Dit proces is vergelijkbaar met autorisatie, maar vindt plaats buiten de laag identiteitsbeheer.

Er zijn verschillende redenen voor deze scheiding:

• Complexiteit van licentiemodellen: Licentieregels zijn vaak complex en specifiek voor het bedrijfsmodel. Licenties kunnen bijvoorbeeld per stoel zijn, op tijd gebaseerde (dagelijkse of maandelijkse toewijzing), gelijktijdig gebruik beperken of specifieke regels voor opnieuw toewijzen hebben. Id-providers zijn over het algemeen ontworpen voor gebruikersverificatie en basisautorisatie, niet voor complexe commerciële licentielogica.

• Onafhankelijkheid: Als u afhankelijk bent van de functies van id-providers voor licentiebeheer, kan uw oplossing worden vergrendeld in die provider of de beperkingen ervan. Als u klanten ondersteunt die verschillende id-providers gebruiken, moet u toch een aangepaste oplossing voor hen bouwen.

Een veelvoorkomend patroon is het beheren van licenties in de database van de toepassing of een toegewezen service. Wanneer een gebruiker zich aanmeldt, haalt de id-provider zijn rechten op en injecteert deze in het autorisatietoken als aangepaste claims die tijdens runtime door de toepassingsonderdelen kunnen worden gecontroleerd.

Identiteitsschaal en verificatievolume

Naarmate multitenant-oplossingen toenemen, neemt het aantal gebruikers en aanmeldingsaanvragen toe dat de oplossing moet verwerken toe. Evalueer deze overwegingen voor schaalbaarheid:

• Beoordeel of de gebruikersdirectory kan opschalen om het vereiste aantal gebruikers te ondersteunen.

• Evalueer of het authenticatieproces het verwachte aantal aanmeldingen en registraties verwerkt.

• Bepaal of er pieken zijn die het verificatiesysteem niet kan verwerken. Bijvoorbeeld, om 9:00 uur Pacific Time kan iedereen in de westelijke Verenigde Staten aan het werk gaan en zich aanmelden bij uw oplossing, waardoor er een piek in aanmeldingsaanvragen ontstaat. Deze scenario's worden ook wel aanmeldingsstormen genoemd.

• Bepaal of hoge belasting in delen van uw oplossing van invloed is op de prestaties van het verificatieproces. Als verificatie bijvoorbeeld vereist dat een API voor een toepassingslaag wordt aangeroepen, kan een piek in verificatieaanvragen van invloed zijn op de algehele systeemprestaties.

• Definieer hoe uw oplossing zich gedraagt als de IdP niet beschikbaar is. Overweeg of een back-upverificatieservice moet worden opgenomen om bedrijfscontinuïteit te behouden.

Medewerkers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Belangrijkste auteurs:

• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Daniel Scott-Raynsford | Partnertechnologie Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

• Jelle Druyts | Principal Customer Engineer, FastTrack voor Azure
• Landon Pierce | Senior klanttechnicus
• Sander van den Hoven | Senior Partner Technology Strategist
• Nick Ward | Senior Cloud Solution Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Gerelateerde resource

• Architectuurbenaderingen voor identiteit in multitenant-oplossingen

Volgende stap

Meer informatie over overwegingen bij het werken met domeinnamen in een multitenant-toepassing.