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-, Schul- oder Unikonten, wenn die Entität über ein Konto in einer 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).

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.

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

Zu den unterstützten Kontotypen gehört die Option Konten in einem beliebigen Organisationsverzeichnis für eine mehrinstanzenfähige Anwendung, damit Sie Benutzer des Organisationsverzeichnisses 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.

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 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.

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.