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 multitenant tijdens de app-registratie in Microsoft Entra. 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 die zijn geabonneerd op Microsoft Dynamics 365 Fraudebeveiliging 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 details met hen te communiceren via een ander mechanisme.

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 waar 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-directory - Multitenant), staat u elke gebruiker van elke Microsoft Entra-directory toe zich aan te melden bij uw multitenant-toepassing. 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 uw 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 voor multitenant-apps zoals eerder 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 ondersteuning biedt voor Security Assertion Markup Language (SAML) voor OpenID Connect. 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.

Apps met gebruikers in andere tenants of andere consumentenaccounts

Zoals wordt weergegeven in het volgende diagram met behulp van een voorbeeld van twee tenants (voor fictieve organisaties, Adatum en Contoso), bevatten ondersteunde accounttypen de accounts in elke organisatiedirectory-optie voor een multitenant-toepassing, zodat u gebruikers van een organisatiedirectory kunt toestaan. Met andere woorden, u staat een gebruiker toe zich met hun eigen identiteit aan te melden bij uw toepassing vanuit elke 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. Tweede diagramtitel: Tenantbeheerder bepaalt hoe de app in zijn tenant werkt met de Enterprise-app voor die app.

Er is slechts één toepassingsregistratie of toepassingsobject. Er is echter een Enterprise-app of Service Principal (SP) in elke tenant waarmee gebruikers zich kunnen 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 volgende diagram. In dit voorbeeld wordt de toepassing geregistreerd in de Adatum-tenant. Gebruiker A van Adatum en Gebruiker B van Contoso kan zich beide aanmelden bij de app met de verwachting gebruiker A van Adatum en die Gebruiker B van Contoso heeft toegang tot Contoso-gegevens.

Diagramtitel: Multitenant-app versus externe identiteiten, ook wel B 2 B genoemd.

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 de 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 en 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 in het volgende diagram wordt geïllustreerd, 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 beveiligt. De gebruiker maakt geen afzonderlijke referentie in de tenant.

Diagramtitel: Multitenant-app versus externe identiteiten, ook wel B 2 B genoemd.

Gastgebruikers verifiëren zich door zich aan te melden bij hun thuistenant, een persoonlijk Microsoft-account of een ander IDP-account (id-provider). 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.
• U kunt autorisatie verkrijgen voor toegang tot resources om te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Door een strategie voor gedelegeerde machtigingen te ontwikkelen, kunt u de beste aanpak implementeren voor het beheren van machtigingen in uw toepassing en 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.