Freigeben über

Einrichten von Anwendungen im Microsoft Entra ID-Ökosystem

  • Artikel

Wenn Sie Anwendungen in Microsoft Entra ID einrichten, richten Sie zuerst eine Identität für eine Anwendung ein. Eine App benötigt eine Identität in Microsoft Entra ID, um Token anfordern zu können. Eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) benötigt eine Identität in Microsoft Entra ID, damit Token für den Zugriff auf Ressourcen ausgestellt werden können.

In diesem Artikel erfahren Sie, wie Sie Apps in einem Microsoft Entra ID-Mandanten im Microsoft Entra Admin Center oder mit der Microsoft Graph-API registrieren können. Dies ist der zweite Artikel in einer Reihe dazu, wie unabhängige Softwareentwickler (Independent Software Developers, ISVs) ihre Anwendungen für Microsoft Entra ID erstellen und optimieren können. In dieser Reihe finden Sie weitere Informationen zu folgenden Themen:

Registrieren von Anwendungen

Entwickler können Anwendungen als mehrinstanzenfähige Apps oder als Einzelmandanten-Apps registrieren. Für ISVs empfiehlt sich die Verwendung mehrinstanzenfähiger Apps. Eine mehrinstanzenfähige App verfügt über eine einzelne App-Registrierung, die vollständig von einem ISV gesteuert und im zugehörigen Mandanten registriert wird. Informationen dazu, wie Sie einen Microsoft Entra ID-Mandanten erstellen, um Ihre App zu registrieren, finden Sie hier.

Um Lösungen für beliebige Kunden bereitzustellen, die Microsoft Entra ID ausführen, und eine nahtlose Erfahrung für die Integration in den Microsoft Entra ID-Mandanten des Kunden zu bieten, navigieren Sie zu Microsoft Entra Admin Center > App-Registrierungen > Anwendung registrieren. Wählen Sie in dieser neuen App-Registrierung Unterstützte Kontotypen > Konten in einem beliebigen Organisationsverzeichnis (beliebiger Microsoft Entra ID-Mandant – mehrinstanzenfähig) oder Konten in einem beliebigen Organisationsverzeichnis (beliebiger Microsoft ID Entra-Mandant – mehrinstanzenfähig) und persönliche Microsoft-Konten (z. B. Skype, Xbox) aus.

Screenshot der Anwendungskonfigurationsoptionen im Microsoft Entra Admin Center.

Das Onboarding einer mehrmandantenfähigen App in einen externen Mandanten kann so einfach sein wie die Ausführung einer App und die Anmeldung von Benutzern bei der App. Wenn der Mandant Benutzereinwilligungen zulässt (was bedeutet, dass Benutzer sich bei Apps anmelden können, ohne dass die App zuvor von einem Administrator genehmigt wurde), ist für die Integration einer App nur die Anmeldung eines Benutzers bei der App erforderlich. In diesem Identitätsworkshop für Entwickler (Zeitcode 1:05:20 bis 1:08:00) wird gezeigt, wie eine App in einen Mandanten integriert wird, während sich ein Benutzer bei einer App anmeldet.

Wenn Sie eine App in einem Microsoft Entra ID-Mandanten registrieren, erhält sie eine Anwendungs-ID (App-ID). Diese wird auch als Client-ID für eine App bezeichnet. Sie identifiziert eine App eindeutig und ist somit vergleichbar mit einer Benutzer-ID (userid) für einen Benutzer. Die App-ID ist in der Microsoft Entra ID-Cloud global eindeutig und unveränderlich. Alle Interaktionen zwischen einer App und Microsoft Entra ID enthalten die App-ID.

Neben der App-ID enthält eine App-Registrierung Informationen zur App, die die App-Entwickler bereits kennen oder wissen müssen. Beispielsweise muss ein App-Entwickler die App-ID kennen, um mit Microsoft Entra ID interagieren zu können. Entwickler wissen, welche Art von Anwendung sie erstellen (Web-App, native App, Single-Page-Webanwendung, mobile App oder Desktop-App). Für Anwendungstypen gibt es erforderliche Attribute.

Ein erforderliches Anwendungsattribut ist beispielsweise ein Umleitungs-URI (Uniform Resource Identifier). Das Attribut teilt Microsoft Entra ID die Webadresse oder die native App-Adresse mit, die nach der Authentifizierung oder Autorisierung an einen Benutzer gesendet werden soll. Der Entwickler kennt die Umleitungs-URIs für eine Anwendung (basierend auf dem App-Typ und dem Ort, an dem die App ausgeführt wird).

Das Manifest einer App (auf das Sie über das Microsoft Entra Admin Center oder mit einer Microsoft Graph-API zugreifen können) speichert die zahlreichen Anwendungsattribute. Weitere Informationen zu App-Attributen und ihren zulässigen Werten finden Sie unter Grundlegendes zum Microsoft Entra-App-Manifest.

Informationen zu empfohlenen Einstellungen für Apps, die Sie entwickeln, finden Sie unter Codebeispiele für die Authentifizierung und Autorisierung mit der Microsoft Identity Platform. Suchen Sie nach einem Anwendungsbeispiel, das der App ähnelt, die Sie erstellen, und lesen Sie die zugehörige Dokumentation. In den Beispielen werden erforderliche App-Registrierungseinstellungen nach App-Typ aufgeführt. Wenn Sie beispielsweise eine API in Node.js erstellen, finden Sie Beispiele, die Sie zu diesen Registrierungsanweisungen führen.

Eine App-Registrierung kommuniziert, was ein Entwickler weiß. In jedem Mandanten, von dem aus Benutzer sich bei Ihrer mehrinstanzenfähigen App authentifizieren können, konfigurieren Mandantenadministratoren, wie Anwendungen in ihrem Mandanten ausgeführt werden. Beispielsweise kann ein Mandantenadministrator eine Richtlinie für bedingten Zugriff festlegen, die eine App auf bestimmte Netzwerkadressen beschränkt. Außerdem kann eine Richtlinie für bedingten Zugriff vorhanden sein, um festzulegen, dass Benutzer nur per Multi-Faktor-Authentifizierung (MFA) auf eine App zugreifen können, oder App-Einstellungen, die bestimmten Benutzern oder Gruppen die Verwendung einer App gestatten.

Um solche Einschränkungen zu ermöglichen, benötigen Mandantenadministratoren Zugriffssteuerungspunkte für Apps in ihrem Mandanten. Microsoft Entra ID erstellt automatisch eine Unternehmensanwendung in jedem Mandanten, in dem ein Benutzer eine App authentifiziert. Im Microsoft Entra Admin Center werden sie Unternehmensanwendungen genannt, die Objekte sind jedoch Dienstprinzipale. Weitere Informationen zu Apps und Dienstprinzipalen in Microsoft Entra ID finden Sie hier.

Nachdem ein Benutzer eine App authentifiziert hat, erstellt Microsoft Entra ID einen Dienstprinzipal in dem Mandanten, über den sich der Benutzer authentifiziert hat. Mandantenadministratoren können das Dienstprinzipalobjekt in Microsoft Graph (oder im Microsoft Entra Admin Center unter Unternehmensanwendungen) verwenden, um die Funktionsweise einer App im Mandanten zu konfigurieren.

Dienstprinzipale sind keine Kopien einer App-Registrierung, obwohl sie viele der gleichen Attribute aufweisen. Stattdessen ist ein Dienstprinzipal mit der zugehörigen App-Registrierung verknüpft. Sie können Aktualisierungen für App-Registrierungen in verknüpften Unternehmensanwendungen anzeigen. Bei mehrinstanzenfähigen Apps hat der Kunde keinen Zugriff auf App-Registrierungen, die im Mandanten des ISV verbleiben. Eine Anwendung kann jedoch mithilfe von Microsoft Graph auf den eigenen Dienstprinzipal zugreifen, auch wenn sich dieser in einem anderen Mandanten befindet. Folglich kann eine App auf Attribute im Zusammenhang mit der Unternehmensanwendung zugreifen, die beispielsweise Aufschluss darüber geben, ob eine Benutzerzuweisung zu einer App erforderlich ist oder welche Benutzer einer Rolle in der App zugewiesen sind.

Für ISVs wird zwar eine mehrinstanzenfähige App für die App-Registrierung empfohlen, eine Einzelmandanten-App ist jedoch eine weitere Option für die Registrierung von Apps. Anstelle einer einzelnen App-Registrierung im Mandanten des ISV, bei dem der ISV uneingeschränkte Kontrolle über die Registrierung hat, können Sie Ihre Kunden bitten, Ihre App in deren Mandanten für Ihre App zu registrieren. Nachdem der Kunde die Registrierung abgeschlossen hat, konfiguriert er Ihre App-Instanz mit den Details seiner App-Registrierung. Dieser Ansatz mit einer Einzelmandanten-App empfiehlt sich in erster Linie für Branchenanwendungen, die für bestimmte Unternehmen entwickelt wurden.

Aufgrund des Zusatzaufwands der kundenseitigen Registrierung und Konfiguration Ihrer Anwendung raten wir ISVs von Einzelmandanten-Apps ab. Es gibt jedoch Szenarien, in denen eine mehrinstanzenfähige App nicht in Frage kommt.

Wenn Ihre App SAML 2.0 (Security Assertion Markup Language) anstelle von OpenID Connect (OIDC) oder OAuth 2.0 verwendet, folgt sie einem Registrierungsmodell für Einzelmandanten-Apps. Bei SAML-Apps werden Dienstprinzipale und App-Registrierung in umgekehrter Reihenfolge erstellt wie bei OIDC- oder OAuth 2.0-App. Das gilt zumindest für den Administrator, der die SAML-App dem Mandanten hinzufügt. Anstatt eine App zu registrieren und den Dienstprinzipal automatisch von Microsoft Entra ID erstellen zu lassen, erstellen Administratoren zunächst eine Unternehmens-App. Microsoft Entra ID erstellt automatisch die App-Registrierung. Der im Abschnitt Veröffentlichen von Anwendungen beschriebene Microsoft Entra ID-App-Katalog vereinfacht die Erstellung von SAML-Apps für Administratoren.

Einschränkungen bei Umleitungs-URIs (Uniform Resource Identifiers, URIs) können dazu führen, dass ein ISV keine mehrinstanzenfähige App erstellen kann. Eine App kann maximal über 256 Umleitungs-URIs verfügen (ohne Platzhalter). Wenn Ihre Anwendung einen eindeutigen Umleitungs-URI für jeden Kunden erfordert und mehr als 256 Kunden eine eindeutige Instanz benötigen, können Sie möglicherweise keine mehrinstanzenfähige App erstellen. Aus Sicherheitsgründen können in Umleitungs-URIs von Microsoft Entra ID keine Platzhalter (*) verwendet werden. Eine Möglichkeit ist, einen einzelnen Umleitungs-URI für Ihren zentralen Dienst zu verwenden (sofern ein zentraler Dienst möglich ist). Der zentrale Umleitungs-URI überprüft das Token und leitet den Benutzer dann an den kundenspezifischen Endpunkt um.

Veröffentlichen von Anwendungen

Wenn Benutzer Ihre App erstmals authentifizieren oder eine App für den Zugriff auf eine Ressource für den Benutzer autorisieren, entscheiden sie, ob sie Ihrer App vertrauen. Administratoren können ähnliche Entscheidungen für alle Benutzer in ihrem Mandanten treffen. Administratoren können entscheiden, ob sich ein Benutzer bei einer App anmeldet und ob eine App auf bestimmte Ressourcen zugreift.

Die folgenden App-Veröffentlichungsmethoden können ISVs dabei helfen, ihre Apps so zu präsentieren, dass Benutzer und Administratoren sie als vertrauenswürdig betrachten.

  • Veröffentlichen Sie Ihre App über eine überprüfte Domäne. Die Herausgeberdomäne informiert Benutzer und Administratoren darüber, an welche Standorte ihre Informationen weitergegeben werden. Die Veröffentlichung über eine überprüfte Herausgeberdomäne zeigt, dass der registrierte Mandant einer App die Kontrolle über die Domäne hat, die als Herausgeber einer App angegeben ist.
  • Veröffentlichen Sie Ihre App mit Herausgeberüberprüfung. Eine überprüfte Herausgeberdomäne ist Voraussetzung für die Herausgeberüberprüfung. Diese geht darüber hinaus, einfach nur zu zeigen, dass ein App-Herausgeber die Kontrolle über eine Domäne hat. Die Herausgeberüberprüfung zeigt, dass Microsoft die Authentizität der zugrunde liegenden Entität der Domäne und des Mandanten überprüft hat. Benutzer ohne Administratorrechte vertrauen häufig keinen mehrinstanzenfähigen Apps von nicht überprüften Herausgebern. Administratoren können Mandanten so konfigurieren, dass Apps, die nicht von überprüften Herausgebern stammen, immer eine Administratoreinwilligung erfordern. Die Herausgeberüberprüfung richtet sich in erster Linie an ISVs, die mehrinstanzenfähige Apps für OAuth 2.0 und OIDC erstellen. Überprüfte Herausgeber sind Mitglieder des Microsoft Cloud-Partnerprogramms. Die Herausgeberüberprüfung wirkt sich nicht auf Einzelmandanten-Apps aus (z. B. solche, die SAML- oder Branchen-Apps verwenden).
  • Veröffentlichen Sie Ihre App im Microsoft Entra ID-App-Katalog. Sie können bei Microsoft die Aufnahme Ihrer Apps mit SAML 2.0 sowie Ihrer Apps mit OAuth 2.0 und OIDC in den Microsoft Entra ID-App-Katalog anfordern. Administratoren gelangen über Microsoft Entra Admin Center > Unternehmensanwendungen > Neue Anwendungen zu vorintegrierten Apps im Microsoft Entra ID-App-Katalog. Die Veröffentlichung Ihrer App im Microsoft Entra ID-App-Katalog vereinfacht und minimiert die Konfiguration für Ihre App. Microsoft testet die Anwendungen und stellt eine Kompatibilitätsüberprüfung bereit. Dies ist besonders für Apps mit SAML 2.0 hilfreich, die vor der Verwendung konfiguriert werden müssen. Sie können die SCIM 2.0-Implementierung (System for Cross-Domain Identity Management) Ihrer App verwenden, um Ihre App-Katalog-App für die Bereitstellung zu konfigurieren. Weitere Informationen finden Sie im Abschnitt Automatische Bereitstellung. Reichen Sie zunächst eine Anforderung zum Veröffentlichen Ihrer Anwendung ein. Sie können einmaliges Anmelden und Benutzerbereitstellung über SCIM mit einer einzelnen Anwendung im App-Katalog erreichen.
  • Nehmen Sie am Microsoft 365-App-Konformitätsprogramm teil. Die Verwendung einer überprüften Domäne zeigt, dass Sie die Kontrolle über Ihre Domäne haben. Die Herausgeberüberprüfung zeigt, dass Microsoft die Authentizität Ihrer Organisation überprüft hat. Die Aufnahme Ihrer App in den Microsoft Entra ID-App-Katalog zeigt, dass Ihre App mit Microsoft Entra ID einfach integriert werden kann. Mit dem Microsoft 365-Konformitätsprogramm können Sie Ihre Kunden mittels Herausgebernachweis, per Microsoft 365-Zertifizierung oder über das Tool zur Automatisierung der App-Compliance (App Compliance Automation Tool, ACAT) in Azure über die Sicherheit und Compliance Ihrer App informieren. Es zeigt, wie Ihre Anwendung Ressourcen schützt, auf die der Kunde den Zugriff durch Ihre App autorisiert.

Automatische Bereitstellung

Die App-Bereitstellung in Microsoft Entra ID kann automatisch Benutzeridentitäten, Gruppenobjekte und Rollen für Cloudanwendungen bereitstellen, auf die Benutzer Zugriff benötigen. Neben der Erstellung von Benutzern und Gruppenobjekten umfasst die automatische Bereitstellung auch die Pflege und Entfernung von Benutzeridentitäten im Falle von Status- oder Rollenänderungen. Der Microsoft Entra-Bereitstellungsdienst stellt Benutzer und Gruppen automatisch für Anwendungen bereit. Hierzu wird ein von einer Anwendung bereitgestellter Endpunkt der SCIM-Objektverwaltungs-API aufgerufen.

Für ISVs hat die App-Bereitstellung in Microsoft Entra ID unter anderem folgende Vorteile:

  • Es ist möglich, Microsoft Graph zur Bereitstellung für Ihre Anwendung zu verwenden. Durch die Erstellung eines SCIM-Endpunkts kann die Bereitstellung mit Identitätsanbietern (IdPs) verwendet werden, die SCIM unterstützen. Die meisten IdPs unterstützen das SCIM-Bereitstellungsprotokoll.
  • Die Bereitstellung ist ein Synchronisierungsvorgang, bei dem Daten zwischen Microsoft Entra ID und einer Anwendung synchronisiert werden. Um eine Microsoft Graph-basierte Synchronisierungslösung zu implementieren, benötigt eine App Zugriff auf alle Attribute aller Benutzer und Gruppen im Mandanten. Einige Microsoft Entra ID-Kunden möchten nur ungern einen solch umfassenden Zugriff gewähren. Mit SCIM kann ein Administrator auswählen, welche Attribute Microsoft Entra ID mit einer Anwendung synchronisiert. Viele Administratoren ziehen diese präzise Steuerung vor, die nur bei einer SCIM-Implementierung zur Verfügung steht.
  • Die Erstellung eines eigenen Microsoft Graph-Synchronisierungsdiensts für die Bereitstellung hat zur Folge, dass Sie diesen Dienst verwalten und ein Pullmodell implementieren müssen, um Microsoft Entra ID auf Änderungen zu überwachen. Wenn Sie einen SCIM-Endpunkt implementieren, kümmert sich Microsoft Entra ID um die Verwaltung des Bereitstellungsdiensts und pusht Änderungen an Ihre App.

Unter Verwenden von SCIM, Microsoft Graph und Microsoft Entra ID zum Bereitstellen von Benutzern und Bereichern von Apps mit Daten erfahren Sie, wann Sie SCIM verwenden sollten und wann Microsoft Graph. Verwenden Sie die Microsoft-Benutzerdokumentation zum Planen, Erstellen und Überprüfen Ihres SCIM-Endpunkts mit Microsoft Entra ID, und behandeln Sie bekannte Probleme bei der Einhaltung des SCIM-Protokolls.

Neben der Datensynchronisierung mit Anwendungen bietet Microsoft Entra ID auch eine Bereitstellung mit cloudbasierten Anwendungen für das Personalwesen (Human Resources, HR). Die personalbasierte Bereitstellung ist die Erstellung digitaler Identitäten auf der Grundlage einer Personallösung. Die Personalsysteme werden zum Autoritätsursprung für diese neu erstellten digitalen Identitäten und sind häufig der Ausgangspunkt zahlreicher Bereitstellungsprozesse. Lokale Personallösungen können Microsoft Identity Manager verwenden, um Benutzer für ein lokales Active Directory bereitzustellen. Anschließend können sie mit Microsoft Entra ID synchronisiert werden – entweder über Microsoft Entra Connect oder direkt.

Mit der API-gesteuerten eingehenden Bereitstellung auf Cloudbasis können ISVs für Personalsoftware native Synchronisierungsfunktionen bereitstellen, sodass Änderungen im Personalsystem automatisch in Microsoft Entra ID und verbundene lokale Active Directory-Domänen einfließen. Beispielsweise kann eine Personal-App oder eine App für ein Studenteninformationssystem Daten an Microsoft Entra ID senden – direkt nach Abschluss einer Transaktion oder als Massenaktualisierung am Ende des Tages. Machen Sie sich zunächst mit den Konzepten der API-gesteuerten eingehenden Bereitstellung vertraut, lernen Sie die bulkUpload-Funktion in Microsoft Graph kennen, und erfahren Sie mehr über Konzepte, Szenarien und Einschränkungen im Zusammenhang mit der API-gesteuerten Bereitstellung.

Nächste Schritte