Delen via

Architectuurbenaderingen voor identiteit in multitenant-oplossingen

Bijna alle multitenant-oplossingen vereisen een identiteitssysteem. In dit artikel worden algemene onderdelen van identiteit beschreven, waaronder verificatie en autorisatie, en hoe u deze onderdelen in een multitenant-oplossing kunt toepassen.

Notitie

Zie architectuuroverwegingen voor identiteiten in een multitenant-oplossing voordat u begint met het bouwen van een identiteitssysteem voor een multitenant-oplossing.

Verificatie

Verificatie is het proces waarmee de identiteit van een gebruiker wordt vastgesteld. Wanneer u een multitenant-oplossing bouwt, moet u rekening houden met de verschillende benaderingen voor verschillende aspecten van het verificatieproces.

Federatie

Mogelijk moet u federeren met externe id-providers (IDP's). U kunt federatie gebruiken om de volgende scenario's in te schakelen:

  • Sociale aanmelding, waarmee gebruikers zich kunnen aanmelden met hun Google-, Facebook-, GitHub- of persoonlijke Microsoft-account

  • Tenantspecifieke directory's, waarmee tenants uw toepassing kunnen federeren met hun eigen ID's, zodat ze accounts op meerdere locaties niet hoeven te beheren

Zie het patroon Federatieve identiteit voor meer informatie.

Als u ervoor kiest om tenantspecifieke ID's te ondersteunen, moet u ervoor zorgen dat u duidelijk maakt welke services en protocollen uw toepassing ondersteunt. Bepaal bijvoorbeeld of het OpenID Connect-protocol en het Security Assertion Markup Language-protocol moeten worden ondersteund of dat federatie moet worden beperkt tot Microsoft Entra ID-exemplaren.

Wanneer u een IdP implementeert, kunt u schalen en limieten overwegen die van toepassing kunnen zijn. Uw IdP kan bijvoorbeeld federeren met slechts een beperkt aantal andere ID's.

Overweeg ook federatie te bieden als een functie die alleen van toepassing is op klanten op een hogere productlaag.

Eenmalige aanmelding

Met eenmalige aanmelding kunnen gebruikers naadloos schakelen tussen toepassingen zonder dat ze op elk moment opnieuw moeten worden geverifieerd.

Wanneer gebruikers een toepassing bezoeken, stuurt de toepassing deze naar een IdP. Als de IdP een bestaande sessie detecteert, geeft deze een nieuw token uit zonder dat de gebruikers hoeven te communiceren met het aanmeldingsproces. Een federatief identiteitsmodel ondersteunt eenmalige aanmelding door gebruikers in staat te stellen één identiteit te gebruiken in meerdere toepassingen.

In een multitenant-oplossing kunt u een andere vorm van eenmalige aanmelding inschakelen. Als gebruikers gemachtigd zijn om toegang te krijgen tot gegevens in meerdere tenants, moet u mogelijk een naadloze ervaring bieden wanneer de gebruikers hun context wijzigen van de ene tenant naar de andere. Overweeg of uw oplossing naadloze overgangen tussen tenants moet ondersteunen. Als dat het geval is, moet u overwegen of uw IdP tokens opnieuw moet uitgeven met specifieke tenantclaims. Wanneer een gebruiker zich bijvoorbeeld aanmeldt bij Azure Portal, kan deze schakelen tussen verschillende Microsoft Entra-id-directory's. Deze overgang activeert opnieuw verificatie en genereert een nieuw token van het zojuist geselecteerde Microsoft Entra ID-exemplaar.

Evaluatie van aanmeldingsrisico's

Moderne identiteitsplatformen ondersteunen een risicoanalyse tijdens het aanmeldingsproces. Als een gebruiker zich bijvoorbeeld aanmeldt vanaf een ongebruikelijke locatie of een ongebruikelijk apparaat, kan het verificatiesysteem extra identiteitscontroles vereisen, zoals meervoudige verificatie (MFA), voordat de aanmeldingsaanvraag kan worden voortgezet.

Overweeg of uw tenants verschillende risicobeleidsregels kunnen hebben die moeten worden toegepast tijdens het verificatieproces. Als u bijvoorbeeld een aantal tenants in een sterk gereglementeerde branche hebt, kunnen ze verschillende risicoprofielen en -vereisten hebben dan tenants die in minder gereglementeerde omgevingen werken. Of u kunt toestaan dat tenants met hogere prijscategorieën meer beperkend aanmeldingsbeleid opgeven dan tenants die een lagere laag van uw service aanschaffen.

Als u verschillende risicobeleidsregels voor elke tenant moet ondersteunen, moet uw verificatiesysteem weten bij welke tenant de gebruiker zich aanmeldt, zodat het juiste beleid kan worden toegepast.

Als uw IdP deze mogelijkheden bevat, kunt u overwegen om de systeemeigen functies voor aanmeldingsrisico's van IdP te gebruiken. Het kan complex en foutgevoelig zijn om deze functies zelf te implementeren.

Als u de id's van de tenants federeert, kunnen hun risicovolle aanmeldingsbeleidsregels worden toegepast, zodat ze het afdwingingsbeleid en de controles kunnen beheren. Als u bijvoorbeeld twee MFA-verificaties vereist, één van de IdP van de gebruiker en een andere van uw eigen systeem, kan dit het aanmeldingsproces moeilijker maken. Zorg ervoor dat u begrijpt hoe federatie communiceert met elk van de IDP's van uw tenant en het beleid dat ze hebben.

Imitatie

Met imitatie kan een gebruiker de identiteit van een andere gebruiker aannemen zonder de referenties van die gebruiker te gebruiken.

Imitatie is over het algemeen gevaarlijk en kan moeilijk te implementeren en beheren zijn. In sommige scenario's is imitatie echter vereist. Als u bijvoorbeeld werkt in een SaaS-omgeving (Software as a Service), moeten uw helpdeskmedewerkers mogelijk de identiteit van een gebruiker aannemen, zodat ze zich kunnen aanmelden als de gebruiker en een probleem kunnen oplossen.

Als u imitatie implementeert, kunt u overwegen om het gebruik ervan te controleren. Zorg ervoor dat uw logboeken zowel de gebruiker bevatten die de actie heeft uitgevoerd als de id van de gebruiker die deze heeft geïmiteerd.

Sommige identiteitsplatformen ondersteunen imitatie, ofwel als een ingebouwde functie of met behulp van aangepaste code. U kunt bijvoorbeeld een aangepaste claim toevoegen in Microsoft Entra External ID voor de gesimuleerde gebruikers-ID, of u kunt de subject-id-claim vervangen in de tokens die worden uitgegeven.

Autorisatie

Autorisatie is het proces om te bepalen wat een gebruiker mag doen.

Autorisatiegegevens kunnen op verschillende plaatsen worden opgeslagen, waaronder op de volgende locaties:

  • In uw IdP: Als u bijvoorbeeld Microsoft Entra-id als uw IdP gebruikt, kunt u functies zoals app-rollen en -groepen gebruiken om autorisatiegegevens op te slaan. Uw toepassing kan vervolgens de bijbehorende tokenclaims gebruiken om uw autorisatieregels af te dwingen.

  • In uw toepassing: U kunt uw eigen autorisatielogica bouwen en vervolgens informatie opslaan over wat elke gebruiker in een database of vergelijkbaar opslagsysteem kan doen. Vervolgens kunt u verfijnde besturingselementen ontwerpen voor autorisatie op basis van rollen of resources.

In de meeste multitenant-oplossingen beheert de klant of tenant rol- en machtigingstoewijzingen en niet de leverancier van het multitenant-systeem.

Tenantidentiteit en rolgegevens toevoegen aan tokens

Bepaal welke onderdelen van uw oplossing autorisatieaanvragen moeten verwerken. Evalueer of een gebruiker toegang heeft tot gegevens van een specifieke tenant.

Een veelvoorkomende benadering is dat uw identiteitssysteem een tenant-id-claim insluit in een token. Met deze methode kan uw toepassing de claim inspecteren en controleren of de gebruikers met de tenant werken waartoe ze toegang hebben. Als u het beveiligingsmodel op basis van rollen gebruikt, kunt u het token uitbreiden met informatie over de rol van de gebruiker binnen de tenant.

Als één gebruiker echter toegang heeft tot meerdere tenants, hebt u mogelijk een manier nodig voor uw gebruikers om aan te geven met welke tenant ze willen werken tijdens het aanmeldingsproces. Nadat de gebruiker de actieve tenant heeft geselecteerd, kan de IdP een token uitgeven dat de juiste tenant-id-claim en -rol voor die tenant bevat. U moet ook overwegen hoe gebruikers kunnen schakelen tussen tenants, waarvoor een nieuw token moet worden uitgegeven.

Autorisatie op basis van toepassingen

Een alternatieve benadering is om het identiteitssysteem agnostisch te maken voor tenant-id's en -rollen. Gebruikers worden geïdentificeerd via hun referenties of een federatierelatie en tokens bevatten geen tenant-id-claim. In een afzonderlijke lijst of database worden records bijgehouden waarvan gebruikers toegang krijgen tot elke tenant. De toepassingslaag controleert vervolgens of een opgegeven gebruiker is gemachtigd om toegang te krijgen tot gegevens voor een specifieke tenant op basis van die lijst.

Gebruik Microsoft Entra ID of Externe ID

Microsoft Entra ID en externe id zijn beheerde identiteitsplatforms die u in uw eigen multitenant-oplossing kunt gebruiken.

Veel multitenant-oplossingen werken als SaaS. Uw keuze voor het gebruik van Microsoft Entra-id of externe id is deels afhankelijk van hoe u uw tenants of klantenbestand definieert.

Belangrijk

Azure AD B2C ondersteunt ook veel van de scenario's in dit artikel. Vanaf 1 mei 2025 is het echter niet meer beschikbaar om te kopen voor nieuwe klanten, dus we raden het niet aan voor nieuwe oplossingen. Zie De veelgestelde vragen over Azure AD B2C voor meer informatie.

Antipatronen om te voorkomen

Uw eigen identiteitssysteem bouwen of uitvoeren

Het bouwen van een modern identiteitsplatform is complex. Hiervoor is ondersteuning vereist voor een reeks protocollen en standaarden, en een onjuiste implementatie kan beveiligingsproblemen veroorzaken. Omdat standaarden en protocollen veranderen, moet u uw identiteitssysteem voortdurend bijwerken om aanvallen te beperken en de nieuwste beveiligingsfuncties op te nemen. Het is ook belangrijk om ervoor te zorgen dat een identiteitssysteem tolerant is omdat downtime ernstige gevolgen kan hebben voor de rest van uw oplossing. In de meeste scenario's profiteert het implementeren van een IdP niet rechtstreeks voor het bedrijf, maar is het noodzakelijk voor het implementeren van een multitenant-service. Het is beter om een gespecialiseerd identiteitssysteem te gebruiken dat experts bouwen, gebruiken en beveiligen.

Wanneer u uw eigen identiteitsbeheer uitvoert, moet u wachtwoordhashes of andere vormen van inloggegevens opslaan, die een aanlokkelijk doelwit voor aanvallers worden. Zelfs het hashen en salten van wachtwoorden is vaak onvoldoende beveiliging, omdat aanvallers voldoende rekenkracht hebben om deze gegevens mogelijk te compromitteren.

Wanneer u een identiteitssysteem uitvoert, bent u verantwoordelijk voor het genereren en distribueren van MFA- of eenmalige wachtwoordcodes. U hebt een mechanisme nodig om deze codes via sms of e-mail te verzenden. U bent ook verantwoordelijk voor het detecteren van gerichte en brute-force-aanvallen, het beperken van aanmeldingspogingen en het onderhouden van auditlogboeken.

In plaats van uw eigen identiteitssysteem te bouwen of te beheren, kunt u het beste een vooraf gemaakte service of onderdeel gebruiken. Denk bijvoorbeeld aan beheerde identiteitsplatforms zoals Microsoft Entra ID of Externe id. Leveranciers van deze platforms zijn verantwoordelijk voor het uitvoeren van de infrastructuur en zorgen doorgaans voor ondersteuning voor de huidige identiteits- en verificatiestandaarden.

Kan niet rekening houden met de vereisten van uw tenants

Tenants hebben vaak sterke voorkeuren voor het beheren van identiteiten in de oplossingen die ze gebruiken. Veel zakelijke klanten vereisen bijvoorbeeld federatie met hun eigen ID's om eenmalige aanmelding in te schakelen en te voorkomen dat meerdere sets referenties worden beheerd. Voor andere tenants zijn mogelijk MFA of extra beveiligingsmaatregelen vereist voor het aanmeldingsproces. Als u deze vereisten niet in overweging neemt tijdens het ontwerp, kan het later lastig zijn om ze toe te voegen.

Zorg ervoor dat u de identiteitsvereisten van uw tenants begrijpt voordat u het ontwerp van uw identiteitssysteem voltooit. Zie Architectuuroverwegingen voor identiteit in een multitenant-oplossing voor meer informatie over specifieke vereisten.

Gebruikers en tenants verwarren

Het is belangrijk om duidelijk te overwegen hoe uw oplossing een gebruiker en een tenant definieert. In veel scenario's kan de relatie complex zijn. Een tenant kan bijvoorbeeld meerdere gebruikers bevatten en één gebruiker kan lid worden van meerdere tenants.

Zorg ervoor dat u een duidelijk proces hebt voor het bijhouden van tenantcontext binnen uw toepassing en aanvragen. In sommige scenario's moet u voor dit proces een tenant-id opnemen in elk toegangstoken en deze valideren voor elke aanvraag. In andere gevallen worden tenantautorisatiegegevens afzonderlijk van gebruikersidentiteiten opgeslagen. Voor deze aanpak is een complexer autorisatiesysteem vereist om te beheren welke gebruikers specifieke bewerkingen binnen elke tenant kunnen uitvoeren.

Het bijhouden van de tenantcontext van een gebruiker of token is van toepassing op elk tenancymodel , omdat een gebruikersidentiteit altijd een tenantcontext heeft binnen een multitenant-oplossing. Het is een goede gewoonte om tenantcontext bij te houden wanneer u onafhankelijke stempels voor één tenant implementeert, die uw codebasis toekomstbestendig maakt voor andere vormen van multitenancy.

Rollen en resource-autorisatie combineren

Het is belangrijk om een autorisatiemodel te kiezen dat bij uw oplossing past. Beveiliging op basis van rollen is eenvoudig te implementeren, maar op resources gebaseerde autorisatie biedt meer verfijnde controle. Evalueer de vereisten van uw tenants en bepaal of ze bepaalde gebruikers moeten autoriseren om alleen toegang te krijgen tot specifieke onderdelen van uw oplossing.

Kan auditlogboeken niet schrijven

Auditlogboeken zijn een belangrijk hulpmiddel om inzicht te krijgen in uw omgeving en hoe gebruikers uw systeem implementeren. Door elke identiteitsgebeurtenis te controleren, kunt u vaak bepalen of uw identiteitssysteem wordt aangevallen en kunt u controleren hoe uw systeem wordt gebruikt. Zorg ervoor dat u auditlogboeken schrijft en opslaat in uw identiteitssysteem. Overweeg of de identiteitscontrolelogboeken van uw oplossing beschikbaar moeten zijn voor tenants om te beoordelen.

Bijdragers

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

Belangrijkste auteurs:

Andere Inzenders:

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