Identiteits- en accounttypen voor apps met één en meerdere tenants

In dit artikel wordt uitgelegd hoe u, als ontwikkelaar, kunt kiezen of uw app alleen gebruikers van uw Microsoft Entra-tenant, elke Microsoft Entra-tenant of gebruikers met persoonlijke Microsoft-accounts toestaat. U kunt uw app configureren als één tenant of meerdere tenants tijdens de app-registratie in Azure. Zorg ervoor dat het zero trust-principe van toegang met minimale bevoegdheden zo is dat uw app alleen machtigingen aanvraagt die nodig is.

Het Microsoft Identity Platform biedt ondersteuning voor specifieke identiteitstypen:

• Werk- of schoolaccounts wanneer de entiteit een account in een Microsoft Entra-id heeft
• Persoonlijke Microsoft-accounts (MSA) voor iedereen die een account heeft in Outlook.com, Hotmail, Live, Skype, Xbox, enzovoort.
• Externe identiteiten in Microsoft Entra ID voor partners (gebruikers buiten uw organisatie)
• Microsoft Entra Business to Customer (B2C) waarmee u een oplossing kunt maken waarmee uw klanten hun andere id-providers kunnen opnemen. Toepassingen die gebruikmaken van Azure AD B2C of zijn geabonneerd op Microsoft Dynamics 365 Fraud Protection met Azure Active Directory B2C , kunnen mogelijke frauduleuze activiteiten beoordelen na pogingen om nieuwe accounts te maken of zich aan te melden bij het ecosysteem van de client.

Een vereist onderdeel van de registratie van toepassingen in Microsoft Entra ID is uw selectie van ondersteunde accounttypen. Hoewel IT-professionals in beheerdersrollen bepalen wie toestemming kan geven voor apps in hun tenant, geeft u als ontwikkelaar op wie uw app kan gebruiken op basis van accounttype. Wanneer een tenant u niet toestaat om uw toepassing te registreren in Microsoft Entra ID, bieden beheerders u een manier om deze gegevens via een ander mechanisme te communiceren.

U kiest uit de volgende ondersteunde accounttypeopties bij het registreren van uw toepassing.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Accounts in deze organisatiemap alleen - één tenant

Wanneer u alleen Accounts in deze organisatiemap selecteert (alleen O365 - één tenant), staat u alleen gebruikers en gasten toe vanuit de tenant waarin de ontwikkelaar hun app heeft geregistreerd. Deze optie is de meest voorkomende voor Lob-toepassingen (Line-Of-Business).

Accounts in elke organisatiemap alleen - multitenant

Wanneer u Accounts selecteert in een organisatiemap (Elke Microsoft Entra-map - Multitenant), staat u elke gebruiker van elke Microsoft Entra-directory toe zich aan te melden bij uw toepassing met meerdere tenants. Als u alleen gebruikers van specifieke tenants wilt toestaan, filtert u deze gebruikers in uw code door te controleren of de nette claim in de id_token op de lijst met toegestane tenants staat. Uw toepassing kan het eindpunt van de organisatie of het algemene eindpunt gebruiken om gebruikers aan te melden in de basistenant van de gebruiker. Als u gastgebruikers wilt ondersteunen die zich aanmelden bij uw multitenant-app, gebruikt u het specifieke tenanteindpunt voor de tenant waar de gebruiker een gast is om zich aan te melden bij de gebruiker.

Accounts in een organisatieaccount en persoonlijke Microsoft-accounts

Wanneer u Accounts selecteert in een organisatieaccount en persoonlijke Microsoft-accounts (Elke Microsoft Entra-directory - Multitenant) en persoonlijke Microsoft-accounts (bijvoorbeeld Skype, Xbox), staat u een gebruiker toe zich met hun eigen identiteit aan te melden bij uw toepassing vanuit een Microsoft Entra-tenant of consumentenaccount. Hetzelfde tenantfilter en hetzelfde eindpuntgebruik zijn van toepassing op deze apps als op apps met meerdere tenants, zoals hierboven beschreven.

Alleen persoonlijke Microsoft-accounts

Wanneer u alleen persoonlijke Microsoft-accounts selecteert , staat u alleen gebruikers met consumentenaccounts toe om uw app te gebruiken.

Klantgerichte toepassingen

Wanneer u een oplossing bouwt in het Microsoft Identity Platform dat uw klanten bereikt, wilt u meestal uw bedrijfsdirectory niet gebruiken. In plaats daarvan wilt u dat de klanten zich in een afzonderlijke adreslijst bevinden, zodat ze geen toegang hebben tot de bedrijfsbronnen van uw bedrijf. Om aan deze behoefte te voldoen, biedt Microsoft Entra Business to Customer (B2C) aan.

Azure AD B2C biedt business-to-customer-identiteit als een service. U kunt toestaan dat gebruikers alleen een gebruikersnaam en wachtwoord voor uw app hebben. B2C ondersteunt klanten met sociale identiteiten om wachtwoorden te verminderen. U kunt zakelijke klanten ondersteunen door uw Azure AD B2C-directory te federeren naar de Microsoft Entra-id van uw klanten (of elke id-provider die SAML ondersteunt) naar OpenID Verbinding maken. In tegenstelling tot een multitenant-app gebruikt uw app niet de bedrijfsdirectory van de klant waar ze hun bedrijfsactiva beschermen. Uw klanten hebben toegang tot uw service of mogelijkheid zonder uw app toegang te geven tot hun bedrijfsbronnen.

Het is niet alleen aan de ontwikkelaar

Terwijl u in uw toepassingsregistratie definieert wie zich kan aanmelden bij uw app, is de laatste uitspraak afkomstig van de afzonderlijke gebruiker of de beheerders van de thuistenant van de gebruiker. Tenantbeheerders willen vaak meer controle over een app hebben dan alleen wie zich kan aanmelden. Ze willen bijvoorbeeld een beleid voor voorwaardelijke toegang toepassen op de app of bepalen welke groep ze toestaan om de toepassing te gebruiken. Als u wilt dat tenantbeheerders dit besturingselement hebben, is er een tweede object in het Microsoft Identity Platform: de Enterprise-app. Bedrijfs-apps worden ook wel service-principals genoemd.

Voor apps met gebruikers in andere tenants of andere consumentenaccounts

Zoals wordt weergegeven in het onderstaande diagram met behulp van een voorbeeld van twee tenants (voor de fictieve organisaties, Adatum en Contoso), bevatten ondersteunde accounttypen de accounts in elke organisatiemapoptie voor een toepassing met meerdere tenants, zodat u gebruikers van de organisatiedirectory kunt toestaan. Met andere woorden, u staat een gebruiker toe zich aan te melden bij uw toepassing met hun eigen identiteit vanaf een Microsoft Entra-id. Er wordt automatisch een service-principal gemaakt in de tenant wanneer de eerste gebruiker van een tenant wordt geverifieerd bij de app.

De GIF-animatie toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van eerste diagram: Service-principal die automatisch wordt gemaakt in de tenant wanneer de eerste gebruiker van een tenant wordt geverifieerd bij de app. Onder de titel van het eerste diagram, aan de linkerkant, bevinden zich twee opsommingstekens: slechts één toepassingsregistratie of toepassingsobject. Enterprise-app, service-principal, in elke tenant waarmee de gebruiker zich kan aanmelden bij de app. Links van de opsommingstekens vertegenwoordigt een cloudshape de Adatum-tenant waarin Adatum de naam is van een fictieve organisatie. Binnen de Adatum-tenantcloudshape vertegenwoordigt een pictogram de App en een ander pictogram de Adatum SP. Een pijl verbindt het app-pictogram met het SP-pictogram. Tweede diagramtitel: Tenantbeheerder bepaalt hoe de app in zijn tenant werkt met de Enterprise-app voor die app. Onder de titel van het tweede diagram, aan de linkerkant, vertegenwoordigt een cloudshape de Adatum-tenant waarin Adatum de naam is van een fictieve organisatie. Rechts van de Adatum-cloudshape vertegenwoordigt een andere cloudshape de Contoso-tenant waarin Contoso de naam is van een fictieve organisatie. Binnen de Contoso-cloudshape vertegenwoordigt een pictogram de Contoso SP. Een pijl verbindt de Adatum-app binnen de Adatum-cloudshape met de Contoso SP binnen de Contoso-cloudshape.

Er is slechts één toepassingsregistratie of toepassingsobject. Met een Enterprise-app of Service Principal (SP) in elke tenant kunnen gebruikers zich echter aanmelden bij de app. De tenantbeheerder kan bepalen hoe de app werkt in de tenant.

Overwegingen voor meerdere tenants-apps

Multitenant-apps melden gebruikers aan bij de basistenant van de gebruiker wanneer de app gebruikmaakt van het algemene eindpunt of het organisatie-eindpunt. De app heeft één app-registratie, zoals wordt weergegeven in het onderstaande diagram. In dit voorbeeld wordt de toepassing geregistreerd in de Adatum-tenant. Gebruiker A van Adatum en Gebruiker B van Contoso kan zich aanmelden bij de app met de verwachting dat gebruiker A van Adatum toegang heeft tot Adatum-gegevens en dat gebruiker B van Contoso toegang heeft tot Contoso-gegevens.

Diagramtitel: Multitenant-app versus externe identiteiten, ook wel B 2 B genoemd. Aan de linkerkant verschijnt 'Adatum' boven een gebouw dat de Adatum-organisatie vertegenwoordigt waar Adatum de naam is van een fictieve organisatie. Aan de rechterkant wordt 'Contoso' weergegeven boven een gebouw om de Contoso-organisatie te vertegenwoordigen waar Contoso de naam is van een fictieve organisatie. Rechts van het Adatum-gebouw staat een vak met de titel Adatum App Registration. Het bevat een pictogram dat de Adatum-gegevens aan de linkerkant vertegenwoordigt en een pictogram dat de Contoso-gegevens aan de rechterkant vertegenwoordigt. Een pijl verbindt het Adatum-gebouw met het vak Adatum App-registratie. In het Adatumgebouw staat een cirkel voor Gebruiker A. Een pijl verbindt Gebruiker A met het vak Adatum App-registratie. Binnen het Contoso-gebouw vertegenwoordigt een cirkel Gebruiker B. Een pijl verbindt Gebruiker B met het vak Adatum App-registratie. Tekst onder aan het diagram, tussen de twee gebouwen: Multitenant-app. Hiermee wordt een algemeen eindpunt gebruikt om u aan te melden. Er is geen uitnodiging/extern account nodig.

Als ontwikkelaar is het uw verantwoordelijkheid om tenantgegevens gescheiden te houden. Als de Contoso-gegevens bijvoorbeeld afkomstig zijn van Microsoft Graph, ziet de gebruiker B van Contoso alleen de Microsoft Graph-gegevens van Contoso. Er is geen mogelijkheid dat gebruiker B van Contoso toegang heeft tot Microsoft Graph-gegevens in de Adatum-tenant, omdat Microsoft 365 echte gegevensscheiding heeft.

In het bovenstaande diagram kan gebruiker B van Contoso zich aanmelden bij de toepassing en hebben ze toegang tot Contoso-gegevens in uw toepassing. Uw toepassing kan gebruikmaken van onze algemene (of organisatie)-eindpunten, zodat de gebruiker zich systeemeigen aanmeldt bij de tenant, waarvoor geen uitnodigingsproces is vereist. Een gebruiker kan uw toepassing uitvoeren en aanmelden. Dit werkt nadat de gebruiker of tenantbeheerder toestemming heeft verleend.

Samenwerking met externe gebruikers

Wanneer ondernemingen gebruikers die geen lid zijn van de onderneming toegang willen geven tot gegevens uit de onderneming, gebruiken ze de functie Microsoft Entra Business to Business (B2B). Zoals u in het onderstaande diagram kunt zien, kunnen ondernemingen gebruikers uitnodigen om gastgebruikers in hun tenant te worden. Nadat de gebruiker de uitnodiging heeft geaccepteerd, heeft deze toegang tot gegevens die de uitnodigende tenant heeft beveiligd. De gebruiker maakt geen afzonderlijke referentie in de tenant.

Diagramtitel: Multitenant-app versus externe identiteiten, ook wel B 2 B genoemd. Aan de linkerkant verschijnt 'Adatum' boven een gebouw dat de Adatum-organisatie vertegenwoordigt. Aan de rechterkant wordt 'Contoso' weergegeven boven een gebouw dat de Contoso-organisatie vertegenwoordigt. Binnen het Contoso-gebouw bevindt zich een cirkel die Gebruiker B vertegenwoordigt. Rechts van het Adatum-gebouw staat een vak met een pictogram voor de Adatum-gegevens- en app-registratie. Een pijl verbindt het Adatum-gebouw met de gegevens en het registratievak. Binnen het Adatumgebouw staat een cirkel voor Gebruiker A. Een pijl verbindt Gebruiker A met de gegevens en het registratievak. Een kleinere cirkel in het Adatumgebouw verbindt zich met een pijl naar Gebruiker B en met een andere pijl naar de gegevens- en registratievak. Tekst onder aan het diagram, tussen de twee gebouwen: Externe identiteiten. Gebruik Adatum-eindpunt om u aan te melden. Kan geen algemeen eindpunt gebruiken. Uitnodiging/extern account nodig.

Gastgebruikers verifiëren zich door zich aan te melden bij hun thuistenant, een persoonlijk Microsoft-account of een ander IDP-account. Gasten kunnen zich ook verifiëren met een eenmalige wachtwoordcode via een e-mail. Nadat gasten zijn geverifieerd, biedt de Microsoft Entra-id van de uitnodigende tenant een token voor toegang tot het uitnodigen van tenantgegevens.

Houd als ontwikkelaar rekening met deze overwegingen wanneer uw toepassing gastgebruikers ondersteunt:

• U moet een tenantspecifiek eindpunt gebruiken bij het aanmelden bij de gastgebruiker. U kunt de algemene eindpunten, organisaties of consumenten niet gebruiken.
• De identiteit van de gastgebruiker verschilt van de identiteit van de gebruiker in hun thuistenant of andere IDP. De oid claim in het token voor een gastgebruiker verschilt van de persoon oid in de eigen tenant.

Volgende stappen

• Hoe en waarom apps worden toegevoegd aan Microsoft Entra ID , legt uit hoe toepassingsobjecten een toepassing beschrijven voor Microsoft Entra-id.
• Aanbevolen beveiligingsprocedures voor toepassingseigenschappen in Microsoft Entra ID hebben betrekking op eigenschappen zoals omleidings-URI, toegangstokens, certificaten en geheimen, de URI van de toepassings-id en het eigendom van de toepassing.
• Het bouwen van apps met een Zero Trust-benadering voor identiteit biedt een overzicht van machtigingen en aanbevolen procedures voor toegang.
• Het verkrijgen van autorisatie voor toegang tot resources helpt u te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Het ontwikkelen van een strategie voor gedelegeerde machtigingen helpt u bij het implementeren van de beste benadering voor het beheren van machtigingen in uw toepassing en het ontwikkelen met behulp van Zero Trust-principes.
• Door een strategie voor toepassingsmachtigingen te ontwikkelen, kunt u beslissen over de benadering van uw toepassingsmachtigingen voor referentiebeheer.