Meld u aan bij een Azure Active Directory-gebruiker met behulp van het toepassingspatroon voor meerdere tenants

  • Artikel
  • 13 minuten om te lezen

Als u een SaaS-toepassing (Software as a Service) aan veel organisaties aanbiedt, kunt u uw toepassing configureren om aanmeldingen van elke Azure Active Directory-tenant (Azure AD) te accepteren. Deze configuratie wordt aangeroepen om uw toepassing meerdere tenants te maken. Gebruikers in elke Azure AD tenant kunnen zich aanmelden bij uw toepassing nadat ze toestemming hebben gegeven voor het gebruik van hun account met uw toepassing.

Als u een bestaande toepassing hebt die een eigen accountsysteem heeft of andere soorten aanmeldingen van andere cloudproviders ondersteunt, is het toevoegen van Azure AD aanmelding vanuit een tenant eenvoudig. Registreer uw app, voeg aanmeldingscode toe via OAuth2, OpenID Connect of SAML en plaats een knop Aanmelden met Microsoft in uw toepassing.

Notitie

In dit artikel wordt ervan uitgegaan dat u al bekend bent met het bouwen van een toepassing met één tenant voor Azure AD. Als u dat niet doet, begint u met een van de quickstarts op de startpagina van de ontwikkelaarshandleiding.

Er zijn vier stappen om uw toepassing te converteren naar een Azure AD app met meerdere tenants:

  1. Uw toepassingsregistratie bijwerken naar multi-tenant
  2. Werk uw code bij om aanvragen naar het /common-eindpunt te verzenden
  3. Werk uw code bij om meerdere verlenerwaarden te verwerken
  4. Gebruikers- en beheerderstoestemming begrijpen en de juiste codewijzigingen aanbrengen

Laten we elke stap in detail bekijken. U kunt ook rechtstreeks naar het voorbeeld een SaaS-webtoepassing met meerdere tenants bouwen die Microsoft Graph aanroept met behulp van Azure AD en OpenID Connect.

Registratie bijwerken om meerdere tenants te zijn

Standaard zijn web-app-/API-registraties in Azure AD één tenant. U kunt uw registratie meerdere tenants maken door de ondersteunde accounttypen te vinden in het deelvenster Verificatie van uw toepassingsregistratie in de Azure Portal en deze in te stellen op Accounts in elke organisatiedirectory.

Voordat een toepassing met meerdere tenants kan worden gemaakt, moet Azure AD de app-id-URI van de toepassing wereldwijd uniek zijn. De URI van de app-id is een van de manieren waarop een toepassing wordt geïdentificeerd in protocolberichten. Voor een toepassing met één tenant is het voldoende dat de URI van de app-id uniek is binnen die tenant. Voor een multitenant toepassing moet deze wereldwijd uniek zijn, zodat Azure Active Directory de toepassing in alle tenants kan vinden. Wereldwijde uniekheid wordt afgedwongen door te vereisen dat de URI van de app-id een hostnaam heeft die overeenkomt met een geverifieerd domein van de Azure Active Directory-tenant.

Apps die zijn gemaakt via de Azure Portal standaard een wereldwijd unieke app-id-URI hebben ingesteld bij het maken van apps, maar u kunt deze waarde wijzigen. Als de naam van uw tenant bijvoorbeeld contoso.onmicrosoft.com, zou een geldige app-id-URI zijn https://contoso.onmicrosoft.com/myapp. Als uw tenant een geverifieerd domein had, contoso.comzou een geldige app-id-URI ook zijn https://contoso.com/myapp. Als de URI van de app-id dit patroon niet volgt, mislukt het instellen van een multitenant toepassing.

Werk uw code bij om aanvragen naar /common te verzenden

In een toepassing met één tenant worden aanmeldingsaanvragen verzonden naar het aanmeldingseindpunt van de tenant. Voor contoso.onmicrosoft.com zou het eindpunt bijvoorbeeld het volgende zijn: https://login.microsoftonline.com/contoso.onmicrosoft.com. Aanvragen die naar het eindpunt van een tenant worden verzonden, kunnen gebruikers (of gasten) in die tenant aanmelden bij toepassingen in die tenant.

Met een toepassing met meerdere tenants weet de toepassing niet vooraf van welke tenant de gebruiker afkomstig is, zodat u geen aanvragen kunt verzenden naar het eindpunt van een tenant. In plaats daarvan worden aanvragen verzonden naar een eindpunt dat multiplexen voor alle Azure AD tenants:https://login.microsoftonline.com/common

Wanneer de Microsoft identity platform een aanvraag ontvangt op het /common-eindpunt, wordt de gebruiker aangemeld en wordt, als gevolg daarvan, gedetecteerd van welke tenant de gebruiker afkomstig is. Het /common-eindpunt werkt met alle verificatieprotocollen die worden ondersteund door de Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0 en WS-Federation.

Het aanmeldingsantwoord voor de toepassing bevat vervolgens een token dat de gebruiker vertegenwoordigt. De waarde van de verlener in het token vertelt een toepassing van waaruit de gebruiker afkomstig is. Wanneer een antwoord wordt geretourneerd van het /common-eindpunt, komt de waarde van de verlener in het token overeen met de tenant van de gebruiker.

Belangrijk

Het /common-eindpunt is geen tenant en is geen verlener, het is slechts een multiplexer. Wanneer u /common gebruikt, moet de logica in uw toepassing om tokens te valideren worden bijgewerkt om rekening te houden met dit.

Werk uw code bij om meerdere verlenerwaarden te verwerken

Webtoepassingen en web-API's ontvangen en valideren tokens van de Microsoft identity platform.

Notitie

Hoewel systeemeigen clienttoepassingen tokens aanvragen en ontvangen van de Microsoft identity platform, doen ze dit om ze naar API's te verzenden, waar ze worden gevalideerd. Systeemeigen toepassingen valideren geen toegangstokens en moeten ze behandelen als ondoorzichtig.

Laten we eens kijken hoe een toepassing tokens valideert die door de Microsoft identity platform worden ontvangen. Voor een toepassing met één tenant wordt normaal gesproken een eindpuntwaarde gebruikt, zoals:

https://login.microsoftonline.com/contoso.onmicrosoft.com

... en gebruikt deze om een metagegevens-URL te maken (in dit geval OpenID Connect) zoals:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

om twee essentiële gegevens te downloaden die worden gebruikt om tokens te valideren: de ondertekeningssleutels en de waarde van de verlener van de tenant.

Elke Azure AD tenant heeft een unieke verlenerwaarde van het formulier:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

... waarbij de GUID-waarde de naam van de veilige versie van de tenant-id van de tenant is. Als u de voorgaande koppeling naar metagegevens selecteert contoso.onmicrosoft.com, kunt u deze verlenerwaarde in het document zien.

Wanneer een toepassing met één tenant een token valideert, wordt de handtekening van het token gecontroleerd op basis van de ondertekeningssleutels uit het metagegevensdocument. Met deze test kan worden gecontroleerd of de waarde van de verlener in het token overeenkomt met de waarde die is gevonden in het metagegevensdocument.

Omdat het /common-eindpunt niet overeenkomt met een tenant en geen verlener is, wordt bij het onderzoeken van de waarde van de verlener in de metagegevens voor /common een sjabloon-URL gebruikt in plaats van een werkelijke waarde:

https://sts.windows.net/{tenantid}/

Daarom kan een toepassing met meerdere tenants tokens niet alleen valideren door de waarde van de verlener in de metagegevens te vergelijken met de issuer waarde in het token. Een toepassing met meerdere tenants heeft logica nodig om te bepalen welke verlenerwaarden geldig zijn en welke niet zijn gebaseerd op het tenant-id-gedeelte van de verlenerwaarde.

Als een toepassing met meerdere tenants bijvoorbeeld alleen aanmelding toestaat van specifieke tenants die zich hebben geregistreerd voor hun service, moet deze de waarde van de uitgever of de tid claimwaarde in het token controleren om ervoor te zorgen dat de tenant zich in de lijst met abonnees bevindt. Als een toepassing met meerdere tenants alleen personen behandelt en geen toegangsbeslissingen neemt op basis van tenants, kan deze de waarde van de verlener helemaal negeren.

In de voorbeelden met meerdere tenants is de validatie van de verlener uitgeschakeld, zodat alle Azure AD tenant zich kan aanmelden.

Als een gebruiker zich kan aanmelden bij een toepassing in Azure AD, moet de toepassing worden weergegeven in de tenant van de gebruiker. Hierdoor kan de organisatie bijvoorbeeld unieke beleidsregels toepassen wanneer gebruikers van hun tenant zich aanmelden bij de toepassing. Voor een toepassing met één tenant is deze registratie eenvoudiger; Dit is het geval wanneer u de toepassing registreert in de Azure Portal.

Voor een toepassing met meerdere tenants bevindt de initiële registratie voor de toepassing zich in de Azure AD tenant die wordt gebruikt door de ontwikkelaar. Wanneer een gebruiker van een andere tenant zich voor het eerst aanmeldt bij de toepassing, vraagt Azure AD hen om toestemming te geven voor de machtigingen die door de toepassing zijn aangevraagd. Als ze toestemming geven, wordt een weergave van de toepassing met de naam een service-principal gemaakt in de tenant van de gebruiker en kan de aanmelding worden voortgezet. Er wordt ook een delegatie gemaakt in de map waarin de toestemming van de gebruiker voor de toepassing wordt vastgelegd. Zie Toepassingsobjecten en service-principal-objecten voor meer informatie over de toepassings- en ServicePrincipal-objecten en hoe deze zich met elkaar verhouden.

Illustreert toestemming voor app met één laag

Deze toestemmingservaring wordt beïnvloed door de machtigingen die door de toepassing zijn aangevraagd. De Microsoft identity platform ondersteunt twee soorten machtigingen, alleen voor apps en gedelegeerd.

  • Een gedelegeerde machtiging verleent een toepassing de mogelijkheid om als aangemelde gebruiker te fungeren voor een subset van de dingen die de gebruiker kan doen. U kunt bijvoorbeeld een toepassing de gedelegeerde machtiging verlenen om de agenda van de aangemelde gebruiker te lezen.
  • Er wordt rechtstreeks een app-machtiging verleend aan de identiteit van de toepassing. U kunt bijvoorbeeld een toepassing de app-machtiging verlenen om de lijst met gebruikers in een tenant te lezen, ongeacht wie is aangemeld bij de toepassing.

Sommige machtigingen kunnen worden toegestaan door een gewone gebruiker, terwijl andere machtigingen de toestemming van een tenantbeheerder vereisen.

Zie De werkstroom voor beheerderstoestemming configureren voor meer informatie over gebruikers- en beheerderstoestemming.

Bij app-specifieke machtigingen is er altijd toestemming van een tenantbeheerder nodig. Als uw toepassing een app-machtiging aanvraagt en een gebruiker zich probeert aan te melden bij de toepassing, wordt er een foutbericht weergegeven met de mededeling dat de gebruiker geen toestemming kan geven.

Voor bepaalde gedelegeerde machtigingen is ook toestemming van een tenantbeheerder vereist. De mogelijkheid om terug te schrijven naar Azure AD als de aangemelde gebruiker vereist bijvoorbeeld toestemming van een tenantbeheerder. Als een gewone gebruiker zich probeert aan te melden bij een toepassing die een gedelegeerde machtiging aanvraagt waarvoor beheerderstoestemming is vereist, krijgt uw toepassing een foutmelding. Of voor een machtiging beheerderstoestemming is vereist, wordt bepaald door de ontwikkelaar die de resource heeft gepubliceerd en kan worden gevonden in de documentatie voor de resource. De documentatie over machtigingen voor de Microsoft Graph API aangeven welke machtigingen beheerderstoestemming vereisen.

Als uw toepassing machtigingen gebruikt waarvoor beheerderstoestemming is vereist, moet u een gebaar hebben, zoals een knop of koppeling waar de beheerder de actie kan initiëren. De aanvraag die uw toepassing voor deze actie verzendt, is de gebruikelijke OAuth2/OpenID Connect-autorisatieaanvraag die ook de prompt=consent querytekenreeksparameter bevat. Zodra de beheerder toestemming heeft gegeven en de service-principal is gemaakt in de tenant van de klant, hebben volgende aanmeldingsaanvragen de prompt=consent parameter niet nodig. Aangezien de beheerder heeft besloten dat de aangevraagde machtigingen acceptabel zijn, worden vanaf dat moment geen andere gebruikers in de tenant om toestemming gevraagd.

Tenantbeheerders kunnen uitschakelen dat normale gebruikers toestemming kunnen geven voor toepassingen. Als dit wordt uitgeschakeld, is er altijd beheerderstoestemming nodig om een toepassing in een tenant te kunnen gebruiken. Als u uw toepassing wilt testen met toestemming van eindgebruikers uitgeschakeld, kunt u de configuratieswitch vinden in de Azure Portal in de sectie Gebruikersinstellingen onder Bedrijfstoepassingen.

De prompt=consent parameter kan ook worden gebruikt door toepassingen die machtigingen aanvragen waarvoor geen beheerderstoestemming is vereist. Een voorbeeld van wanneer dit wordt gebruikt, is als voor de toepassing een ervaring is vereist waarbij de tenantbeheerder zich eenmalig registreert en vanaf dat moment geen andere gebruikers om toestemming wordt gevraagd.

Als voor een toepassing beheerderstoestemming is vereist en een beheerder zich aanmeldt zonder dat de prompt=consent parameter wordt verzonden, wordt deze alleen toegepast op het gebruikersaccount wanneer de beheerder toestemming geeft voor de toepassing. Normale gebruikers kunnen zich nog steeds niet aanmelden of toestemming geven voor de toepassing. Deze functie is handig als u de tenantbeheerder de mogelijkheid wilt geven om uw toepassing te verkennen voordat u andere gebruikers toegang geeft.

Uw toepassing kan meerdere lagen hebben, die elk worden vertegenwoordigd door een eigen registratie in Azure AD. Bijvoorbeeld een systeemeigen toepassing die een web-API aanroept of een webtoepassing die een web-API aanroept. In beide gevallen vraagt de client (systeemeigen app of web-app) machtigingen aan om de resource (web-API) aan te roepen. Om de client toestemming te geven voor de tenant van een klant, moeten alle resources waarvoor machtigingen worden aangevraagd, al aanwezig zijn in de tenant van de klant. Als niet aan deze voorwaarde wordt voldaan, retourneert Azure AD een fout dat de resource eerst moet worden toegevoegd.

Meerdere lagen in één tenant

Dit kan een probleem zijn als uw logische toepassing bestaat uit twee of meer toepassingsregistraties, bijvoorbeeld een afzonderlijke client en resource. Hoe krijgt u de resource eerst in de tenant van de klant? Azure AD behandelt dit geval door client en resource in één stap toestemming te geven. De gebruiker ziet het totaal van de machtigingen die zijn aangevraagd door zowel de client als de resource op de toestemmingspagina. Als u dit gedrag wilt inschakelen, moet de toepassingsregistratie van de resource de app-id van de client bevatten als een knownClientApplications in het toepassingsmanifest. Bijvoorbeeld:

"knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Dit wordt gedemonstreerd in een systeemeigen client die web-API-voorbeeld aanroept in de sectie Gerelateerde inhoud aan het einde van dit artikel. In het volgende diagram ziet u een overzicht van toestemming voor een app met meerdere lagen die is geregistreerd in één tenant.

Illustreert toestemming voor bekende client-app met meerdere lagen

Meerdere lagen in meerdere tenants

Een soortgelijk geval treedt op als de verschillende lagen van een toepassing zijn geregistreerd in verschillende tenants. Denk bijvoorbeeld aan het bouwen van een systeemeigen clienttoepassing die de Exchange Online API aanroept. Als u de systeemeigen toepassing wilt ontwikkelen en later de systeemeigen toepassing wilt uitvoeren in de tenant van een klant, moet de Exchange Online service-principal aanwezig zijn. In dit geval moeten de ontwikkelaar en de klant Exchange Online aanschaffen om de service-principal in hun tenants te kunnen maken.

Als het een API is die is gebouwd door een andere organisatie dan Microsoft, moet de ontwikkelaar van de API een manier bieden om hun klanten toestemming te geven voor de toepassing in de tenants van hun klanten. Het aanbevolen ontwerp is voor de externe ontwikkelaar om de API te bouwen, zodat deze ook kan functioneren als een webclient om registratie te implementeren. Om dit te doen:

  1. Volg de eerdere secties om ervoor te zorgen dat de API de registratie-/codevereisten voor meerdere tenants implementeert.
  2. Naast het beschikbaar maken van de bereiken/rollen van de API, moet u ervoor zorgen dat de registratie de machtiging 'Aanmelden en gebruikersprofiel lezen' bevat (standaard opgegeven).
  3. Implementeer een aanmeldings-/registratiepagina in de webclient en volg de richtlijnen voor beheerderstoestemming .
  4. Zodra de gebruiker toestemming heeft gegeven voor de toepassing, worden de koppelingen voor service-principals en toestemmingsdelegering gemaakt in hun tenant en kan de systeemeigen toepassing tokens voor de API ophalen.

In het volgende diagram ziet u een overzicht van toestemming voor een app met meerdere lagen die is geregistreerd in verschillende tenants.

Illustreert toestemming voor app met meerdere lagen met meerdere partijen

Gebruikers en beheerders kunnen toestemming voor uw toepassing op elk gewenst moment intrekken:

Als een beheerder toestemming verleent voor een toepassing voor alle gebruikers in een tenant, kunnen gebruikers de toegang niet afzonderlijk intrekken. Alleen de beheerder kan de toegang intrekken en alleen voor de hele toepassing.

Toepassingen met meerdere tenants en tokens voor cachingtoegang

Toepassingen met meerdere tenants kunnen ook toegangstokens krijgen om API's aan te roepen die worden beveiligd door Azure AD. Een veelvoorkomende fout bij het gebruik van de Microsoft Authentication Library (MSAL) met een toepassing met meerdere tenants is om in eerste instantie een token aan te vragen voor een gebruiker die gebruikmaakt van /common, een antwoord te ontvangen en vervolgens een volgend token aan te vragen voor dezelfde gebruiker die ook gebruikmaakt van /common. Omdat het antwoord van Azure AD afkomstig is van een tenant, niet /gemeenschappelijk, slaat MSAL het token op als afkomstig van de tenant. De volgende aanroep naar /common voor het ophalen van een toegangstoken voor de gebruiker mist de cachevermelding en de gebruiker wordt gevraagd zich opnieuw aan te melden. Om te voorkomen dat de cache ontbreekt, moet u ervoor zorgen dat volgende aanroepen voor een reeds aangemelde gebruiker worden gedaan naar het eindpunt van de tenant.

Gerelateerde inhoud

Volgende stappen

In dit artikel hebt u geleerd hoe u een toepassing bouwt waarmee u een gebruiker kunt aanmelden vanuit elke Azure AD tenant. Nadat u Single Sign-On (SSO) hebt ingeschakeld tussen uw app en Azure AD, kunt u uw toepassing ook bijwerken voor toegang tot API's die beschikbaar worden gesteld door Microsoft-resources zoals Microsoft 365. Hiermee kunt u een persoonlijke ervaring bieden in uw toepassing, zoals het weergeven van contextuele informatie aan de gebruikers, zoals hun profielfoto of hun volgende agenda-afspraak.

Ga naar Microsoft Graph API voor meer informatie over het maken van API-aanroepen naar Azure AD- en Microsoft 365-services, zoals Exchange, SharePoint, OneDrive, OneNote en meer.