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

In dit artikel wordt uitgelegd hoe u, als ontwikkelaar, kunt kiezen of uw app alleen gebruikers van uw Azure Active Directory-tenant (Azure AD), elke Azure AD-tenant of gebruikers met persoonlijke Microsoft-accounts toestaat door uw app te configureren als één tenant of multitenant tijdens de app-registratie in Azure en ervoor te zorgen dat de Zero Trust principe van toegang met minimale bevoegdheden, zodat uw app alleen machtigingen aanvraagt die nodig zijn.

De Microsoft identity platform biedt ondersteuning voor specifieke identiteitstypen:

  • Werk- of schoolaccounts wanneer de entiteit een account heeft in een Azure Active Directory (AD)

  • Persoonlijke Microsoft-accounts (MSA) voor iedereen die een account heeft in outlook.com, Hotmail, Live, Skype, Xbox, enzovoort.

  • Externe identiteiten in Azure AD voor partners (gebruikers buiten uw organisatie)

  • Azure AD Business to Customer (B2C) waarmee u een oplossing kunt maken waarmee uw klanten hun andere id-providers kunnen opnemen.

Een vereist onderdeel van de toepassingsregistratie in Azure AD 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 worden gebruikt op basis van accounttype. Wanneer een tenant u niet toestaat om uw toepassing te registreren in Azure AD, 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.

  • Alleen accounts in deze organisatiemap (alleen O365 - één tenant)

  • Accounts in elke organisatiemap (Elke Azure AD directory - Multitenant)

  • Accounts in elke organisatiedirectory (Any Azure AD directory - Multitenant) en persoonlijke Microsoft-accounts (bijvoorbeeld Skype, Xbox)

  • Alleen persoonlijke Microsoft-accounts

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 uit de tenant waarin de ontwikkelaar zijn app heeft geregistreerd. Dit is de meest voorkomende keuze voor LOB-toepassingen (Line-Of-Business).

Alleen accounts in elke organisatiemap - multitenant

Wanneer u Accounts selecteert in een organisatiemap (elke Azure AD directory - Multitenant), staat u elke gebruiker van elke Azure AD directory toe om 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 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. Ter ondersteuning van gastgebruikers 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 Azure AD directory - Multitenant) en persoonlijke Microsoft-accounts (bijvoorbeeld Skype, Xbox), kunt u een gebruiker zich met hun eigen identiteit aanmelden bij uw toepassing vanuit elke Azure AD tenant- of consumentenaccount. Dezelfde tenantfiltering en hetzelfde eindpuntgebruik zijn van toepassing op deze apps als voor multitenant-apps, 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 de Microsoft identity platform die bij uw klanten terechtkomt, wilt u meestal uw bedrijfsdirectory niet gebruiken. In plaats daarvan wilt u dat de klanten zich in een afzonderlijke directory bevinden, zodat ze geen toegang hebben tot de bedrijfsbronnen van uw bedrijf. Om aan deze behoefte te voldoen, biedt Microsoft Azure AD Business to Customer (B2C) aan.

Azure Active Directory B2C biedt business-to-customer-identificatie als een service. Naast het inschakelen van uw app-gebruikers alleen een gebruikersnaam en wachtwoord voor uw app, stelt B2C u in staat om klanten te ondersteunen met de sociale identiteit die u hen toestaat om ze mee te nemen, zodat ze niet meer wachtwoorden hoeven te onthouden. U kunt bijvoorbeeld toestaan dat gebruikers hun Facebook- of Twitter-id gebruiken. U kunt ook enterprise-klanten ondersteunen door uw Azure AD B2C-directory te federeren naar de Azure AD van uw klanten (of een id-provider (IDP) die SAML ondersteunt) naar OpenID Connect. In tegenstelling tot een multitenant-app gebruikt uw app niet de bedrijfsdirectory van de klant waar ze hun bedrijfsactiva beveiligen. Met B2C kunnen uw klanten toegang krijgen tot uw service of mogelijkheid zonder uw app toegang te verlenen tot hun bedrijfsbronnen.

Het is niet alleen aan de ontwikkelaar

Hoewel u, als ontwikkelaar, definieert in uw toepassingsregistratie wie u toestaat om u aan te melden bij uw app, hebt u niet de laatste vraag of een specifieke gebruiker, of gebruikers van een specifieke tenant, zich kunnen aanmelden bij uw app. De laatste opmerking is 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. Om tenantbeheerders in staat te stellen dit besturingselement te hebben, is er een tweede object in de 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 weergegeven in het onderstaande diagram met behulp van een voorbeeld van twee tenants (voor fictieve organisaties, Adatum en Contoso), bevatten ondersteunde accounttypen de accounts in elke organisatiemapoptie voor een toepassing met meerdere tenants, zodat u gebruikers van organisatiedirectory's kunt toestaan. Met andere woorden, u staat een gebruiker toe om zich met hun eigen identiteit aan te melden bij uw toepassing vanaf elke Azure AD. Er wordt automatisch een service-principal gemaakt in de tenant wanneer de eerste gebruiker van een tenant wordt geverifieerd bij de app.

diagram illustreert multitenant-toepassing waarmee gebruikers van organisatiedirectory's kunnen worden toegestaan

Er is slechts één toepassingsregistratie of toepassingsobject, maar er is een Enterprise-app, of Service Principal (SP), in elke tenant waarmee de gebruiker zich kan aanmelden bij de app. De tenantbeheerder kan bepalen hoe de app werkt in hun tenant met de Enterprise-app voor die app.

Overwegingen voor meerdere tenants-apps

Multitenant-apps melden gebruikers aan bij de basistenant van de gebruiker wanneer de app het algemene eindpunt of het organisatie-eindpunt gebruikt. 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 beide 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.

Diagram illustreert multitenant-apps die gebruikers aanmelden vanuit de thuistenant van de gebruiker wanneer de app gebruikmaakt van een gemeenschappelijk of organisatie-eindpunt

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 voor gebruiker B van Contoso om toegang te krijgen 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, waar die tenant zich ook bevindt en er is geen uitnodigingsproces vereist. Een gebruiker kan gewoon uw toepassing uitvoeren en zich 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 van de onderneming, maakt de functie Azure AD Business to Business (B2B) dit mogelijk. Zoals geïllustreerd in het onderstaande diagram, 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.

diagram illustreert ondernemingen gastgebruikers uitnodigen voor hun tenant

Wanneer een gastgebruiker zich moet verifiëren, meldt hij zich aan bij zijn thuistenant, een persoonlijk Microsoft-account, een account van een andere IDP of met een eenmalige wachtwoordcode met behulp van een e-mailaccount. Nadat ze zijn geverifieerd met hun IDP, biedt de uitnodigende tenant Azure AD de toepassing een token waarmee deze worden geïdentificeerd als gastgebruiker in de tenant. Deze gastgebruiker heeft vervolgens toegang tot de gegevens in de uitnodigende tenant.

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, organisatie- of consumenteneindpunten niet gebruiken.

  • De identiteit van de gastgebruiker verschilt van de identiteit van de gebruiker in hun thuistenant of andere IDP. Dit betekent dat de oid-claim in het token voor een gastgebruiker anders is dan de oid van dezelfde persoon in hun thuistenant.

Volgende stappen