Identitäts- und Kontotypen für einzel- und mehrinstanzenfähige Apps

Dieser Artikel erläutert, wie Sie auswählen können, ob Ihre App nur Benutzer aus Ihrem Microsoft Entra-Mandanten, aus jedem Microsoft Entra-Mandanten oder Benutzer mit persönlichen Microsoft-Konten zulässt. Sie können Ihre App während der App-Registrierung in Microsoft Entra für einzelne oder mehrere Mandanten 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) ermöglicht Ihnen das Erstellen einer Lösung, 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, bieten Administratoren Ihnen eine Möglichkeit, diese Details über einen anderen Mechanismus an sie zu übermitteln.

Sie wählen bei der Registrierung Ihrer Anwendung zwischen den 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 Nur Konten in diesem Organisationsverzeichnis (nur O365 – einzelner Mandant) auswählen, lassen Sie nur Benutzer und Gäste aus dem Mandanten zu, 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 – mehrere Mandanten) auswählen, können sich alle Benutzer aus beliebigen Microsoft Entra-Verzeichnissen bei Ihrer mehrinstanzenfä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 TID-Anspruch im id_token in Ihrer Liste der zulässigen Mandanten befindet. Ihre Anwendung kann den Endpunkt der Organisationen oder den gemeinsamen Endpunkt verwenden, um Benutzer im Basismandanten des Benutzers anzumelden. Um die Anmeldung bei Ihrer Mehrinstanzen-App für Gastbenutzer zu unterstützen, verwenden Sie für die Anmeldung den genauen Mandantenendpunkt für den Mandanten, in dem der Benutzer ein Gast ist.

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. Für diese Apps gelten die gleiche Mandantenfilterung und die gleiche Endpunktnutzung wie zuvor für mehrinstanzenfähige Apps beschrieben.

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 der Microsoft Entra ID-Instanz Ihrer Kunden oder einem beliebigen Identitätsanbieter verbinden, der Security Assertion Markup Language (SAML) mit OpenID Connect unterstützt. 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. Beispielsweise können sie 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.

Apps mit Benutzern in anderen Mandanten oder anderen Verbraucherkonten

Wie im folgenden Diagramm unter Verwendung eines Beispiels mit zwei Mandanten (für die fiktiven Organisationen Adatum und Contoso) dargestellt, schließen die unterstützten Kontotypen die Option Konten in einem beliebigen Organisationsverzeichnis für eine mehrinstanzenfähige Anwendung ein, sodass Sie Organisationsverzeichnisbenutzer zulassen können. Anders gesagt erlauben Sie es einem Benutzer, sich mit seiner nativen Identität aus 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. Zweiter Diagrammtitel: Administrator steuert, wie die App in ihrem Mandanten mit der Enterprise-App für diese App arbeitet.

Es gibt nur ein Anwendungsregistrierung- oder Anwendungsobjekt. Es gibt jedoch in jedem Mandanten eine Enterprise-App oder einen Dienstprinzipal (Service Principal, SP), die bzw. der es Benutzern ermöglicht, sich bei der App anzumelden. 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, wobei angenommen wird, dass Benutzer A von Adatum auf Adatum-Daten und der Benutzer B von Contoso auf Contoso-Daten zugreift.

Diagrammtitel: Mehrere Mandanten im Vergleich mit externen Identitäten, auch als B2B bezeichnet.

Als Entwickler liegt es in Ihrer Verantwortung, Mandanteninformationen getrennt zu halten. Wenn beispielsweise die Contoso-Daten aus Microsoft Graph stammen, sieht 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 die allgemeinen Endpunkte (oder Organisationsendpunkte) verwenden, sodass sich der Benutzer nativ bei seinem Mandanten anmeldet und kein Einladungsprozess erforderlich ist. Ein Benutzer kann Ihre Anwendung ausführen und sich bei dieser anmelden, sobald 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 einladen, Gastbenutzer in ihrem Mandanten zu werden. Nachdem ein Benutzer die Einladung angenommen hat, kann er auf Daten zugreifen, die der einladende Mandant schützt. Der Benutzer erstellt keine separaten Anmeldeinformationen im Mandanten.

Diagrammtitel: Mehrere Mandanten im Vergleich mit externen Identitäten, auch als B2B bezeichnet.

Gastbenutzer authentifizieren sich, indem Sie sich bei ihrem privaten Mandanten, ihrem persönlichen Microsoft-Konto oder einem anderen IDP-Konto (Identity Provider) 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 der oid derselben Person in ihrem 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.
• Erwerben der Autorisierung für den Zugriff auf Ressourcen hilft Ihnen zu verstehen, wie Sie beim Abrufen von Ressourcenzugriffsberechtigungen für Ihre Anwendung Zero Trust am besten sicherstellen können.
• Entwickeln einer Strategie mit delegierten Berechtigungen hilft Ihnen, den besten Ansatz für die Verwaltung von Berechtigungen in Ihrer Anwendung zu implementieren und mithilfe von Zero Trust-Prinzipien zu entwickeln.
• Entwickeln einer Strategie für Anwendungsberechtigungen hilft Ihnen bei der Entscheidung über den Ansatz Ihrer Anwendungsberechtigungen für die Verwaltung von Anmeldeinformationen.