Identitäts- und Kontotypen für Einzel- und Mehrinstanzen-Apps

In diesem Artikel wird erläutert, wie Sie als Entwickler auswählen können, ob Ihre App nur Benutzer aus Ihrem Microsoft Entra-Mandanten, jedem Microsoft Entra-Mandanten oder Benutzern mit persönlichen Microsoft-Konten zulässt. Sie können Ihre App entweder als einzel- oder mehrinstanzfähig während der App-Registrierung in Azure konfigurieren. Stellen Sie sicher, dass das Zero Trust-Prinzip der geringsten Zugriffsrechte eingehalten wird, so dass Ihre App nur die Berechtigungen anfordert, die sie tatsächlich benötigt.

Die Microsoft Identity Platform bietet Unterstützung für bestimmte Identitätstypen:

• Geschäfts- oder Schulkonten, wenn die Entität über ein Konto in Microsoft Entra ID verfügt
• Persönliche Microsoft-Konten (MSA) für alle Personen, die über ein Konto in Outlook.com, Hotmail, Live, Skype, Xbox usw. verfügen
• Externe Identitäten in Microsoft Entra ID für Partner (Benutzer außerhalb Ihrer Organisation)
• Microsoft Entra Business to Customer (B2C), mit dem Sie eine Lösung erstellen können, mit der Ihre Kunden ihre anderen Identitätsanbieter einbinden können. Anwendungen, die Azure AD B2C verwenden oder Microsoft Dynamics 365 Fraud Protection mit Azure Active Directory B2C abonniert haben, können potenziell betrügerische Aktivitäten nach Versuchen bewerten, neue Konten zu erstellen oder sich beim Ökosystem des Clients anzumelden.

Ein erforderlicher Teil der Anwendungsregistrierung in Microsoft Entra ID ist Ihre Auswahl unterstützter Kontotypen. Während IT-Experten in Administratorrollen entscheiden, wer Apps in ihrem Mandanten zustimmen kann, geben Sie als Entwickler an, wer Ihre App basierend auf dem Kontotyp verwenden kann. Wenn ein Mandant Ihnen nicht erlaubt, Ihre Anwendung in Microsoft Entra ID zu registrieren, geben Administratoren Ihnen die Möglichkeit, diese Details über einen anderen Mechanismus an sie zu übermitteln.

Sie wählen bei der Registrierung Ihrer Anwendung die folgenden unterstützten Kontotypoptionen aus.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Nur Konten in diesem Organisationsverzeichnis - einzelner Mandant

Wenn Sie „Konten“ nur in diesem Organisationsverzeichnis (nur O365 – Einzelner Mandant) auswählen, können Sie nur Benutzer und Gäste aus dem Mandanten zulassen, in dem der Entwickler seine App registriert hat. Diese Option ist am häufigsten für Branchenanwendungen (Line of Business) geeignet.

Nur Konten in beliebigem Organisationsverzeichnis – mehrinstanzfähig

Wenn Sie Konten in einem beliebigen Organisationsverzeichnis (beliebiges Microsoft Entra-Verzeichnis – mehrinstanzfähig) auswählen, können Sie jeden Benutzer aus einem beliebigen Microsoft Entra-Verzeichnis bei Ihrer mehrinstanzfähigen Anwendung anmelden. Wenn Sie nur Benutzer von bestimmten Mandanten zulassen möchten, filtern Sie diese Benutzer in Ihrem Code, indem Sie überprüfen, ob sich der Anspruch „tid“ im id-Token in Ihrer Liste der zugelassenen Mandanten befindet. Ihre Anwendung kann den Endpunkt der Organisationen oder den gemeinsamen Endpunkt verwenden, um Benutzer im Basismandanten des Benutzers anzumelden. Um Gastbenutzer bei der Anmeldung bei Ihrer mehrinstanzfähigen App zu unterstützen, verwenden Sie den bestimmten Mandantenendpunkt für den Mandanten, in dem der Benutzer ein Gast ist, der den Benutzer anmeldet.

Konten in einem beliebigen Organisationskonto und persönliche Microsoft-Konten

Wenn Sie Konten in einem beliebigen Organisationskonto und persönlichen Microsoft-Konten (beliebiges Microsoft Entra-Verzeichnis – Multitenant) und persönlichen Microsoft-Konten (z. B. Skype, Xbox)auswählen, können Sie sich von jedem Microsoft Entra-Mandanten oder Verbraucherkonto bei Ihrer Anwendung mit ihrer nativen Identität anmelden. Die gleiche Mandantenfilter- und Endpunktverwendung gelten für diese Apps wie oben beschrieben für Multitenant-Apps.

Nur persönliche Microsoft-Konten

Wenn Sie nur persönliche Microsoft-Konten auswählen, können Nur Benutzer mit Consumerkonten Ihre App verwenden.

Kundenorientierte Anwendungen

Wenn Sie eine Lösung in der Microsoft Identity Platform erstellen, die Ihre Kunden erreicht, sollten Sie in der Regel nicht Ihr Unternehmensverzeichnis verwenden. Stattdessen sollten sich die Kunden in einem separaten Verzeichnis befinden, damit sie nicht auf die Unternehmensressourcen Ihres Unternehmens zugreifen können. Um diese Anforderung zu erfüllen, bietet Microsoft Microsoft Entra Business für Kunden (B2C) an.

Azure AD B2C bietet Business-to-Customer-Identität als Dienst. Sie können Benutzern nur für Ihre App einen Benutzernamen und ein Kennwort erteilen. B2C unterstützt Kunden mit sozialen Identitäten, um die Anzahl der Kennwörter zu reduzieren. Sie können Unternehmenskunden unterstützen, indem Sie Ihr Azure AD B2C-Verzeichnis mit Microsoft Entra ID Ihrer Kunden (oder einem beliebigen Identitätsanbieter, der SAML unterstützt) mit OpenID verbinden. Im Gegensatz zu einer Mehrinstanzen-App verwendet Ihre App nicht das Unternehmensverzeichnis des Kunden, in dem sie ihre Unternehmensressourcen schützen. Ihre Kunden können auf Ihren Dienst oder Ihre Funktion zugreifen, ohne Ihrer App Zugriff auf ihre Unternehmensressourcen zu gewähren.

Es ist nicht nur Aufgabe des Entwicklers.

Während Sie in Ihrer Anwendungsregistrierung definieren, wer sich bei Ihrer App anmelden kann, stammt das letzte Wort vom einzelnen Benutzer oder den Administratoren des Heimmandanten des Benutzers. Mandantenadministratoren möchten häufig mehr Kontrolle über eine App haben, als nur wer sich anmelden kann. Sie können z. B. eine Richtlinie für bedingten Zugriff auf die App anwenden oder steuern, welche Gruppe sie für die Verwendung der Anwendung zulassen. Damit Mandantenadministratoren über dieses Steuerelement verfügen können, gibt es ein zweites Objekt in der Microsoft Identity Platform: die Enterprise-App. Unternehmens-Apps werden auch als Dienstprinzipale bezeichnet.

Für Apps mit Benutzern in anderen Mandanten oder anderen Consumerkonten

Wie im folgenden Diagramm unter Verwendung eines Beispiels von zwei Mandanten (für die fiktiven Organisationen, Adatum und Contoso) gezeigt, enthalten unterstützte Kontotypen die Konten in einer beliebigen Organisationsverzeichnisoption für eine mehrinstanzfähige Anwendung, sodass Sie Organisationsverzeichnisbenutzer zulassen können. Mit anderen Worten, Sie ermöglichen es einem Benutzer, sich mit seiner nativen Identität von jeder Microsoft Entra ID bei Ihrer Anwendung anzumelden. Ein Dienstprinzipal wird automatisch im Mandanten erstellt, wenn sich der erste Benutzer von einem Mandanten bei der App authentifiziert.

Das animierte GIF zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Dienstprinzipal wird automatisch im Mandanten erstellt, wenn sich der erste Benutzer von einem Mandanten bei der App authentifiziert. Unter dem ersten Diagrammtitel links befinden sich zwei Aufzählungszeichen: Nur eine Anwendungsregistrierung oder ein Anwendungsobjekt. Enterprise-App, Dienstprinzipal, in jedem Mandanten, der es dem Benutzer ermöglicht, sich bei der App anzumelden. Links neben den Aufzählungszeichen stellt ein Cloud-Shape den Adatum-Mandanten dar, wobei Adatum der Name einer fiktiven Organisation ist. Innerhalb des Adatum-Mandanten-Cloud-Shape stellt ein Symbol die App und ein anderes Symbol den Adatum SP dar. Ein Pfeil verbindet das App-Symbol mit dem SP-Symbol. Zweiter Diagrammtitel: Administrator steuert, wie die App in ihrem Mandanten mit der Enterprise-App für diese App arbeitet. Unter dem zweiten Diagrammtitel auf der linken Seite stellt ein Cloud-Shape den Adatum-Mandanten dar, wobei Adatum der Name einer fiktiven Organisation ist. Rechts neben dem Adatum-Cloud-Shape stellt ein anderes Cloud-Shape den Contoso-Mandanten dar, wobei Contoso der Name einer fiktiven Organisation ist. Innerhalb des Contoso-Cloud-Shapes stellt ein Symbol den Contoso-SP dar. Ein Pfeil verbindet die Adatum-App innerhalb des Adatum-Cloud-Shapes mit dem Contoso-SP innerhalb des Contoso-Cloud-Shapes.

Es gibt nur ein Anwendungsregistrierung- oder Anwendungsobjekt. Eine Enterprise-App oder ein Dienstprinzipal (Service Principal, SP) in jedem Mandanten ermöglicht Benutzern jedoch die Anmeldung bei der App. Der Administrator kann steuern, wie die App in ihrem Mandanten funktioniert.

Überlegungen zur Mehrinstanzen-App

Mehrinstanzenfähige Apps melden sich von Benutzern aus dem Privaten Mandanten des Benutzers an, wenn die App den gemeinsamen Endpunkt oder den Organisationsendpunkt verwendet. Die App verfügt über eine App-Registrierung, wie im folgenden Diagramm dargestellt. In diesem Beispiel wird die Anwendung im Adatum-Mandanten registriert. Benutzer A von Adatum und Benutzer B von Contoso können sich beide bei der App anmelden mit der Erwartung, dass Benutzer A von Adatum auf Adatum-Daten und Benutzer B von Contoso auf Contoso-Daten zugreifen wird.

Diagrammtitel: Multitenant App vs. Externe Identitäten, auch bekannt als B 2 . Auf der linken Seite wird „Adatum“ über einem Gebäude angezeigt, das die Adatum-Organisation darstellt, wobei Adatum der Name einer fiktiven Organisation ist. Auf der rechten Seite wird „Contoso“ über einem Gebäude angezeigt, das die Contoso-Organisation darstellt, wobei Contoso der Name einer fiktiven Organisation ist. Rechts neben dem Adatum-Gebäude befindet sich ein Feld mit dem Titel Adatum-App-Registrierung. Es enthält ein Symbol, das die Adatum-Daten auf der linken Seite und ein Symbol, das die Contoso-Daten auf der rechten Seite darstellt. Ein Pfeil verbindet das Adatum-Gebäude mit dem Feld „Adatum-App-Registrierung“. Innerhalb des Adatum-Gebäudes steht ein Kreis für Benutzer A. Ein Pfeil verbindet Benutzer A mit dem Feld „Adatum-App-Registrierung“. Innerhalb des Contoso-Gebäudes steht ein Kreis für Benutzer B. Ein Pfeil verbindet Benutzer B mit dem Feld „Adatum-App-Registrierung“. Text am unteren Rand des Diagramms zwischen den beiden Gebäuden: Multitenant-App. Verwendet den gemeinsamen Endpunkt für die Anmeldung. Es ist keine Einladung/externes Konto erforderlich.

Als Entwickler liegt es in Ihrer Verantwortung, Mandanteninformationen getrennt zu halten. Wenn beispielsweise die Contoso-Daten aus Microsoft Graph stammen, sieht der Benutzer B von Contoso nur die Microsoft Graph-Daten von Contoso. Es gibt keine Möglichkeit für Benutzer B von Contoso, auf Microsoft Graph-Daten im Adatum-Mandanten zuzugreifen, da Microsoft 365 eine echte Datentrennung aufweist.

Im obigen Diagramm kann sich Benutzer B von Contoso bei der Anwendung anmelden und auf Contoso-Daten in Ihrer Anwendung zugreifen. Ihre Anwendung kann unsere gemeinsamen Endpunkte (oder Organisationsendpunkte) verwenden, damit sich der Benutzer nativ bei ihrem Mandanten anmeldet und keinen Einladungsprozess erfordert. Ein Benutzer kann Ihre Anwendung ausführen und sich bei ihr anmelden, was möglich ist, nachdem der Benutzer oder Mandantenadministrator seine Zustimmung erteilt hat.

Zusammenarbeit mit externen Benutzern

Wenn Unternehmen Benutzern, die keine Mitglieder des Unternehmens sind, den Zugriff auf Daten aus dem Unternehmen ermöglichen möchten, verwenden sie das Feature Microsoft Entra Business to Business (B2B). Wie im folgenden Diagramm dargestellt, können Unternehmen Benutzer dazu einladen, Gastbenutzer in ihrem Mandanten zu werden. Nachdem der Benutzer die Einladung angenommen hat, kann er auf Daten zugreifen, die der einladende Mandant geschützt hat. Der Benutzer erstellt keine separaten Anmeldeinformationen im Mandanten.

Diagrammtitel: Multitenant App vs. Externe Identitäten, auch bekannt als B 2 B. Auf der linken Seite wird „Adatum“ über einem Gebäude angezeigt, das die Adatum-Organisation darstellt. Rechts wird „Contoso“ über einem Gebäude angezeigt, das die Contoso-Organisation darstellt. Innerhalb des Contoso-Gebäudes ist ein Kreis, der Benutzer B darstellt. Rechts neben dem Adatum-Gebäude stellt ein Feld mit einem Symbol die Adatum-Daten- und App-Registrierung dar. Ein Pfeil verbindet das Adatum-Gebäude mit dem Daten- und Registrierungsfeld. Innerhalb des Adatum-Gebäudes steht ein Kreis für Benutzer A. Ein Pfeil verbindet Benutzer A mit dem Daten- und Registrierungsfeld. Ein Pfeil verbindet einen kleineren Kreis innerhalb des Adatum-Gebäudes mit Benutzer B; ein weiterer Pfeil verbindet den Kreis mit dem Daten- und Registrierungsfeld. Text am unteren Rand des Diagramms zwischen den beiden Gebäuden: Externe Identitäten. Verwenden Sie den Adatum-Endpunkt, um sich anzumelden. Gemeinsamer Endpunkt kann nicht verwendet werden. Einladung/externes Konto erforderlich.

Gastbenutzer authentifizieren sich, indem Sie sich bei ihrem Privaten Mandanten, ihrem persönlichen Microsoft-Konto oder einem anderen IDP-Konto anmelden. Gäste können sich auch mit einer einmal Kennung per E-Mail authentifizieren. Nach der Authentifizierung der Gäste stellt die Microsoft Entra-ID des eingeladenen Mandanten ein Token für den Zugriff auf die Daten des Mandanten bereit.

Beachten Sie als Entwickler diese Überlegungen, wenn Ihre Anwendung Gastbenutzer unterstützt:

• Sie müssen einen mandantenspezifischen Endpunkt verwenden, wenn sich der Gastbenutzer anmeldet. Sie können die allgemeinen Endpunkte, Organisationen oder Verbraucher nicht verwenden.
• Die Gastbenutzeridentität unterscheidet sich von der Identität des Benutzers in seinem Privaten Mandanten oder einem anderen IDP. Der oid Anspruch im Token für einen Gastbenutzer unterscheidet sich von denselben oid Personen in seinem Heimmandanten.

Nächste Schritte

• Wie und warum Apps zu Microsoft Entra ID hinzugefügt werden, erläutert, wie Anwendungsobjekte eine Anwendung für Microsoft Entra ID beschreiben.
• Bewährte Methoden für die Sicherheit von Anwendungseigenschaften in Microsoft Entra ID umfassen Eigenschaften wie Umleitungs-URI, Zugriffstoken, Zertifikate und Geheimnisse, Anwendungs-ID-URI und Anwendungsbesitz.
• Erstellen von Apps mit einem Zero Trust-Ansatz für Identität bietet eine Übersicht über Berechtigungen und bewährte Methoden für den Zugriff.
• Wenn Sie die Autorisierung für den Zugriff auf Ressourcen erwerben, können Sie besser verstehen, wie Sie Zero Trust beim Abrufen von Ressourcenzugriffsberechtigungen für Ihre Anwendung am besten sicherstellen können.
• Durch Entwickeln einer delegierten Berechtigungsstrategie können Sie den besten Ansatz für die Verwaltung von Berechtigungen in Ihrer Anwendung implementieren und mithilfe von Zero Trust-Grundsätzen entwickeln.
• Die Entwicklung der Strategie für Anwendungsberechtigungen hilft Ihnen bei der Entscheidung über den Ansatz ihrer Anwendungsberechtigungen für die Verwaltung von Anmeldeinformationen.