Hoe en waarom toepassingen worden toegevoegd aan Microsoft Entra-id

Er zijn twee representaties van toepassingen in Microsoft Entra ID:

• Toepassingsobjecten: hoewel er uitzonderingen zijn, kunnen toepassingsobjecten worden beschouwd als de definitie van een toepassing.
• Service-principals : kan worden beschouwd als een exemplaar van een toepassing. Service-principals verwijzen doorgaans naar een toepassingsobject en naar één toepassingsobject kan worden verwezen door meerdere service-principals in verschillende directory's.

Wat zijn toepassingsobjecten en waar komen ze vandaan?

U kunt toepassingsobjecten beheren in het Microsoft Entra-beheercentrum via de App-registraties ervaring. Toepassingsobjecten beschrijven de toepassing naar Microsoft Entra-id en kunnen worden beschouwd als de definitie van de toepassing, zodat de service weet hoe tokens aan de toepassing moeten worden uitgeven op basis van de instellingen. Het toepassingsobject bestaat alleen in de basismap, zelfs als het een toepassing met meerdere tenants is die service-principals in andere mappen ondersteunt. Het toepassingsobject kan een van de volgende zaken bevatten (maar niet beperkt tot):

• Naam, logo en uitgever
• Omleidings-URI's
• Geheimen (symmetrische en/of asymmetrische sleutels die worden gebruikt om de toepassing te verifiëren)
• API-afhankelijkheden (OAuth)
• Gepubliceerde API's/resources/bereiken (OAuth)
• De app-rollen
• Metagegevens en configuratie van eenmalige aanmelding (SSO)
• Metagegevens en configuratie van gebruikers inrichten
• Proxymetagegevens en -configuratie

Toepassingsobjecten kunnen worden gemaakt via meerdere paden, waaronder:

• Toepassingsregistraties in het Microsoft Entra-beheercentrum
• Een nieuwe toepassing maken met Visual Studio en deze configureren voor het gebruik van Microsoft Entra-verificatie
• Wanneer een beheerder een toepassing toevoegt vanuit de app-galerie (waarmee ook een service-principal wordt gemaakt)
• De Microsoft Graph API of PowerShell gebruiken om een nieuwe toepassing te maken
• Vele andere, waaronder verschillende ontwikkelaarservaringen in Azure en in API Explorer-ervaringen in ontwikkelaarscentra

Wat zijn service-principals en waar komen ze vandaan?

U kunt service-principals beheren in het Microsoft Entra-beheercentrum via de ervaring bedrijfstoepassingen. Service-principals bepalen welke toepassing verbinding maakt met Microsoft Entra-id en kan worden beschouwd als het exemplaar van de toepassing in uw directory. Voor elke toepassing kan deze maximaal één toepassingsobject hebben (dat is geregistreerd in een 'basismap') en een of meer service-principalobjecten die exemplaren van de toepassing vertegenwoordigen in elke map waarin deze fungeert.

De service-principal kan het volgende omvatten:

• Een verwijzing naar een toepassingsobject via de eigenschap toepassings-id
• Records van toewijzingen van lokale gebruikers- en groepstoepassingsrollen
• Records van lokale gebruikers- en beheerdersmachtigingen die zijn verleend aan de toepassing
  • Bijvoorbeeld: machtiging voor de toepassing voor toegang tot het e-mailadres van een bepaalde gebruiker
• Records van lokaal beleid, inclusief beleid voor voorwaardelijke toegang
• Records van alternatieve lokale instellingen voor een toepassing
  • Claimtransformatieregels
  • Kenmerktoewijzingen (inrichting van gebruikers)
  • Directoryspecifieke app-rollen (als de toepassing aangepaste rollen ondersteunt)
  • Adreslijstspecifieke naam of logo

Net als toepassingsobjecten kunnen service-principals ook worden gemaakt via meerdere paden, waaronder:

• Wanneer gebruikers zich aanmelden bij een toepassing van derden die is geïntegreerd met Microsoft Entra ID
  • Tijdens het aanmelden wordt gebruikers gevraagd om de toepassing toestemming te geven om toegang te krijgen tot hun profiel en andere machtigingen. De eerste persoon die toestemming geeft, zorgt ervoor dat een service-principal die de toepassing vertegenwoordigt, wordt toegevoegd aan de directory.
• Wanneer gebruikers Microsoft onlineservices zoals Microsoft 365, Microsoft Entra ID of Microsoft Azure gebruiken of zich aanmelden bij Microsoft.
  • Wanneer u een Microsoft-service voor het eerst gebruikt, kunnen een of meer service-principals worden gemaakt in de directory die de verschillende Microsoft-service-identiteiten vertegenwoordigen die worden gebruikt om de service te leveren. Deze 'Just-In-Time'-inrichting kan op elk gewenst moment plaatsvinden, vaak als onderdeel van een achtergrondproces. In zeldzame gevallen kan aan de Microsoft-service-principal die wordt gemaakt, ook een directoryrol worden toegewezen, zoals 'Adreslijstlezers'.
  • Sommige Microsoft-services zoals SharePoint Online maken doorlopend service-principals om veilige communicatie tussen onderdelen, inclusief werkstromen, mogelijk te maken.
• Wanneer een beheerder een toepassing toevoegt vanuit de app-galerie (hiermee wordt ook een onderliggend app-object gemaakt)
• Een toepassing toevoegen om de Microsoft Entra-toepassingsproxy te gebruiken
• Een toepassing voor eenmalige aanmelding verbinden met SAML of wachtwoord-SSO
• Programmatisch via de Microsoft Graph API of PowerShell

Hoe zijn toepassingsobjecten en service-principals gerelateerd aan elkaar?

Een toepassing heeft één toepassingsobject in de basismap waarnaar wordt verwezen door een of meer service-principals in elk van de directory's waar het werkt (inclusief de basismap van de toepassing).

In het voorgaande diagram onderhoudt Microsoft twee mappen intern (weergegeven aan de linkerkant) die worden gebruikt voor het publiceren van toepassingen:

• One for Microsoft Apps (Microsoft-services directory)
• Een voor vooraf geïntegreerde toepassingen van derden (app-galeriemap)

Toepassingsuitgevers/leveranciers die integreren met Microsoft Entra ID zijn vereist om een publicatiemap te hebben (rechts weergegeven als 'Sommige SaaS-adreslijst (Software as a Service).

Toepassingen die u zelf toevoegt (weergegeven als app (die van u) in het diagram zijn onder andere:

• Apps die u hebt ontwikkeld (geïntegreerd met Microsoft Entra ID)
• Apps die u hebt verbonden voor eenmalige aanmelding
• Apps die u hebt gepubliceerd met behulp van de Microsoft Entra-toepassingsproxy

Notities en uitzonderingen

• Niet alle service-principals verwijzen terug naar een toepassingsobject. Toen Microsoft Entra ID oorspronkelijk werd gebouwd, waren de services die aan toepassingen werden geleverd beperkter en was de service-principal voldoende voor het tot stand brengen van een toepassingsidentiteit. De oorspronkelijke service-principal was dichter bij het Windows Server Active Directory-serviceaccount. Daarom is het nog steeds mogelijk om service-principals te maken via verschillende paden, zoals het gebruik van Microsoft Graph PowerShell, zonder eerst een toepassingsobject te maken. De Microsoft Graph API vereist een toepassingsobject voordat u een service-principal maakt.
• Niet alle hierboven beschreven informatie wordt momenteel programmatisch weergegeven. Het volgende is alleen beschikbaar in de gebruikersinterface:
  • Claimtransformatieregels
  • Kenmerktoewijzingen (inrichting van gebruikers)
• Zie de microsoft Graph API-referentiedocumentatie voor meer informatie over de service-principal en toepassingsobjecten:
  • Toepassing
  • Service-principal

Waarom kunnen toepassingen worden geïntegreerd met Microsoft Entra ID?

Toepassingen worden toegevoegd aan Microsoft Entra ID om een of meer van de services te gebruiken die het biedt, waaronder:

• Toepassingsverificatie en -autorisatie
• Gebruikersverificatie en -autorisatie
• Eenmalige aanmelding met federatie of wachtwoord
• Inrichting en synchronisatie van gebruikers
• Op rollen gebaseerd toegangsbeheer (RBAC): gebruik de directory om toepassingsrollen te definiëren voor het uitvoeren van verificatiecontroles op basis van rollen in een toepassing
• OAuth-autorisatieservices - gebruikt door Microsoft 365 en andere Microsoft-toepassingen om toegang tot API's/resources te autoriseren
• Toepassing publiceren en proxy - Een toepassing publiceren van een particulier netwerk naar internet
• Kenmerken van de directoryschema-extensie : het schema van service-principal- en gebruikersobjecten uitbreiden om extra gegevens op te slaan in Microsoft Entra-id

Wie is gemachtigd om toepassingen toe te voegen aan mijn Microsoft Entra-exemplaar?

Standaard hebben alle gebruikers in uw directory rechten om toepassingsobjecten te registreren die ze ontwikkelen en naar eigen goeddunken bepalen welke toepassingen ze delen/toegang geven tot hun organisatiegegevens via toestemming. Als een persoon de eerste gebruiker in uw directory is om u aan te melden bij een toepassing en toestemming te verlenen, wordt er een service-principal in uw tenant gemaakt. Anders worden de toestemmingstoestemmingsgegevens opgeslagen op de bestaande service-principal.

Gebruikers toestaan om toepassingen te registreren en toestemming te geven, kunnen in eerste instantie goed klinken, maar houd rekening met de volgende redenen:

• Toepassingen kunnen Al vele jaren Windows Server Active Directory gebruiken voor gebruikersverificatie zonder dat de toepassing moet worden geregistreerd of vastgelegd in de directory. Nu heeft de organisatie de zichtbaarheid verbeterd om precies te bepalen hoeveel toepassingen de directory gebruiken en voor welk doel.
• Het delegeren van deze verantwoordelijkheden aan gebruikers ontkent de noodzaak van een door beheerders gestuurd registratie- en publicatieproces. Met Active Directory Federation Services (ADFS) was het waarschijnlijk dat een beheerder een toepassing moest toevoegen als relying party namens hun ontwikkelaars. Ontwikkelaars kunnen nu selfservice gebruiken.
• Gebruikers die zich aanmelden bij toepassingen die hun organisatieaccounts gebruiken voor zakelijke doeleinden, zijn een goede zaak. Als ze vervolgens de organisatie verlaten, verliezen ze automatisch de toegang tot hun account in de toepassing die ze gebruikten.
• Een record hebben van welke gegevens zijn gedeeld met welke toepassing een goede zaak is. Gegevens zijn meer transporteerbaar dan ooit en het is handig om een duidelijke record te hebben over wie welke gegevens met welke toepassingen hebben gedeeld.
• API-eigenaren die Microsoft Entra-id voor OAuth gebruiken, bepalen precies welke machtigingen gebruikers kunnen verlenen aan toepassingen en welke machtigingen een beheerder nodig heeft om akkoord te gaan. Alleen beheerders kunnen toestemming geven voor grotere bereiken en belangrijkere machtigingen, terwijl gebruikerstoestemming is afgestemd op de eigen gegevens en mogelijkheden van de gebruikers.
• Wanneer een gebruiker een toepassing toevoegt of toestaat om toegang te krijgen tot de gegevens, kan de gebeurtenis worden gecontroleerd, zodat u de auditrapporten in het Microsoft Entra-beheercentrum kunt bekijken om te bepalen hoe een toepassing is toegevoegd aan de directory.

Als u nog steeds wilt voorkomen dat gebruikers in uw directory toepassingen registreren en zich niet kunnen aanmelden bij toepassingen zonder goedkeuring door de beheerder, zijn er twee instellingen die u kunt wijzigen om deze mogelijkheden uit te schakelen:

• Als u de instellingen voor gebruikerstoestemming in uw organisatie wilt wijzigen, raadpleegt u Configureren hoe gebruikers toestemming geven voor toepassingen.

• Om te voorkomen dat gebruikers hun eigen toepassingen registreren:

  1. Blader in het Microsoft Entra-beheercentrum naar gebruikersinstellingen voor identiteitsgebruikers>>.
  2. Gebruikers kunnen toepassingen registreren op Nee.