Delen via

Toepassingsmodel

  • Artikel

Toepassingen kunnen gebruikers zelf aanmelden of aanmelding delegeren bij een id-provider. In dit artikel worden de stappen beschreven die nodig zijn om een toepassing te registreren bij het Microsoft identity platform.

Een toepassing registreren

Als een id-provider wil weten of een gebruiker toegang heeft tot een bepaalde app, moeten zowel de gebruiker als de toepassing bij de id-provider worden geregistreerd. Wanneer u uw toepassing registreert bij Microsoft Entra ID, biedt u een identiteitsconfiguratie voor uw toepassing waarmee deze kan worden geïntegreerd met het Microsoft Identity Platform. Als u de app registreert, kunt u ook het volgende doen:

  • De huisstijl van uw toepassing aanpassen in het dialoogvenster voor de aanmelding. Deze huisstijl is belangrijk omdat aanmelden het eerste is wat een gebruiker met de app doet.
  • Bepalen of u wilt toestaan dat gebruikers zich alleen kunnen aanmelden als ze deel uitmaken van uw organisatie. Deze architectuur wordt een toepassing met één tenant genoemd. U kunt gebruikers ook toestaan zich aan te melden met een werk- of schoolaccount, dat ook wel een multitenant-toepassing wordt genoemd. U kunt ook persoonlijke Microsoft-accounts of een sociaal account van LinkedIn, Google, enzovoort toestaan.
  • Bereikmachtigingen aanvragen. U kunt bijvoorbeeld het bereik user.read aanvragen, waarmee toestemming wordt verleend om het profiel van de aangemelde gebruiker te lezen.
  • Bereiken definiëren die toegang tot uw web-API definiëren. Wanneer een app toegang wil krijgen tot uw API, moet de app doorgaans machtigingen aanvragen voor de bereiken die u definieert.
  • Een geheim delen met het Microsoft identity platform waarmee de identiteit van de app wordt aangetoond. Het gebruik van een geheim is relevant in het geval dat de app een vertrouwelijke clienttoepassing is. Een vertrouwelijke clienttoepassing is een toepassing die referenties veilig kan bevatten, zoals een webclient. Een vertrouwde back-endserver is vereist om de referenties op te slaan.

Nadat de app is geregistreerd, krijgt deze een unieke id die wordt gedeeld met het Microsoft identity platform wanneer er tokens worden aangevraagd. Als de app een vertrouwelijke clienttoepassing is, wordt ook het geheim of de openbare sleutel gedeeld, afhankelijk van het feit of er certificaten of geheimen zijn gebruikt.

Het Microsoft identity platform vertegenwoordigt toepassingen met behulp van een model dat aan twee hoofdfuncties voldoet:

  • Identificeren van de app door de verificatieprotocollen die worden ondersteund.
  • Opgeven van alle id's, URL's, geheimen en gerelateerde informatie die voor het verifiëren nodig zijn.

Het Microsoft identity platform:

  • Bewaart alle gegevens die nodig zijn om verificatie tijdens runtime te ondersteunen.
  • Bewaart alle gegevens om te beslissen welke resources een app mogelijk nodig heeft en onder welke omstandigheden aan een bepaalde aanvraag moet worden tegemoetgekomen.
  • Biedt infrastructuur voor het implementeren van app-inrichting binnen de tenant van de app-ontwikkelaar en voor elke andere Microsoft Entra-tenant.
  • Verwerkt gebruikerstoestemming tijdens het aanvragen van het token en maakt het dynamisch inrichten van apps in tenants mogelijk.

Toestemming is het proces waarbij, onder specifieke machtigingen, een resource-eigenaar namens de resource-eigenaar autorisatie verleent aan een clienttoepassing voor toegang tot beveiligde resources. Het Microsoft identity platform maakt het volgende mogelijk:

  • Dat gebruikers en beheerders de app dynamisch toestemming kunnen geven of weigeren om namens hen resources te gebruiken.
  • Dat beheerders kunnen beslissen wat apps mogen doen, welke gebruikers gebruik mogen maken van specifieke apps en hoe de directoryresources kunnen worden benaderd.

Apps met meerdere tenants

In het Microsoft identity platform beschrijft een toepassingsobject een toepassing. Tijdens de implementatie gebruikt het Microsoft identity platform het toepassingsobject als blauwdruk om een service-principal te maken; deze vertegenwoordigt een concreet exemplaar van een toepassing binnen een directory of tenant. De service-principal bepaalt wat de app daadwerkelijk kan doen in een specifieke doeldirectory, wie deze mag gebruiken, tot welke resources deze toegang heeft en meer. Het Microsoft identity platform maakt op basis van toestemming een service-principal van een toepassingsobject.

In het volgende diagram staat een vereenvoudigde inrichtingsstroom van Microsoft identity platform op basis van toestemming. Er worden twee tenants getoond: A en B.

  • Tenant A is eigenaar van de toepassing.
  • Tenant B instantieert de toepassing via een service-principal.

Diagram met een vereenvoudigde inrichtingsstroom op basis van toestemming.

De inrichtingsstroom verloopt als volgt:

  1. Een gebruiker wil zich vanaf tenant B aanmelden bij de app. Het autorisatie-eindpunt vraagt een token voor de toepassing aan.
  2. De gebruikersreferenties worden verkregen en geverifieerd.
  3. De gebruiker wordt gevraagd de app toestemming te geven om toegang te verkrijgen tot tenant B.
  4. Het Microsoft identity platform gebruikt het toepassingsobject in tenant A als blauwdruk voor het maken van een service-principal in tenant B.
  5. De gebruiker ontvangt het aangevraagde token.

U kunt dit proces voor meerdere tenants herhalen. Tenant A bevat de blauwdruk voor de app (toepassingsobject). De gebruikers en beheerders van de overige tenants waarvoor de app toestemming heeft, behouden controle over wat de toepassing mag doen. Dit kan worden beheerd met het bijbehorende service-principalobject in elke tenant. Zie Toepassings- en service-principalobjecten in het Microsoft identity platform voor meer informatie.

Volgende stappen

Zie de volgende artikelen voor meer informatie over verificatie en autorisatie in het Microsoft identity platform:

Zie de volgende artikelen voor meer informatie over het toepassingsmodel: