Entwicklung einer Microsoft Entra-App

• 3 Minuten

Nachdem Sie nun über ein besseres Verständnis der grundlegenden Prinzipien und Vorteile von Microsoft Entra ID verfügen, müssen Sie bestimmen, wie Sie seine Funktionen verwenden können, um die Authentifizierung und Autorisierung für Ihre Anwendung zu implementieren. Sie wissen, dass Sie zur Sicherung der Daten Ihrer Kunden sicherstellen müssen, dass Ihre Implementierung in die PostgreSQL-Zugriffssteuerungsmechanismen integriert werden kann. Sie haben sich entschieden, zunächst die Aufgaben zu identifizieren, die mit der Entwicklung, Bereitstellung und Verwaltung von Microsoft Entra-Anwendungen verbunden sind. Sie möchten auch bestimmen, wie Sie den Zugriff auf Ihre Anwendung für mehrere Kunden ermöglichen können.

Was sind die primären anwendungsbezogenen Microsoft Entra ID-Aufgaben?

Um Microsoft Entra ID-basierte Anwendungen zu implementieren, müssen Sie mehrere anwendungsbezogene Verwaltungsaufgaben durchführen, einschließlich der Registrierung, der Konfiguration der Berechtigungen und der Verwaltung ihrer Geheimnisse.

Was ist eine Anwendungsregistrierung?

Beim Betrieb in einer Microsoft Entra-Umgebung authentifiziert sich ein Benutzer bei einer Anwendung in zwei Phasen:

1. Zunächst überprüft Microsoft Entra ID die Identität des Benutzers. Nach erfolgreicher Authentifizierung gibt Microsoft Entra ID Token aus, die Informationen über die erfolgreiche Authentifizierung enthalten.
2. Der Benutzer übergibt Token an die Anwendung. Die Anwendung überprüft die Sicherheitstoken des Benutzers, um sicherzustellen, dass die Authentifizierung erfolgreich war.

Um eine solche Prüfung durchzuführen, muss die Anwendung sicher mit Microsoft Entra ID kommunizieren können. Dies erfordert wiederum, dass die Anwendung selbst als Microsoft Entra-Sicherheitsprinzipal fungiert. Um dies zu ermöglichen, müssen Sie sicherstellen, dass die Anwendung in irgendeiner Form im gleichen Microsoft Entra-Mandanten dargestellt ist, der das Konto des authentifizierenden Benutzers enthält.

Es gibt zwei Darstellungen einer Anwendung in Microsoft Entra ID:

• Ein Anwendungsobjekt, das die Eigenschaften der Anwendung definiert.
• Ein Dienstprinzipal, der Authentifizierungs- und Autorisierungsfunktionen bereitstellt und auf das Anwendungsobjekt verweist.

Sie können Anwendungsobjekte direkt im Azure-Portal auf dem Blatt App-Registrierungen erstellen. Für Ihre eigenen benutzerdefinierten Anwendungen erstellt eine solche Registrierung automatisch den entsprechenden Dienstprinzipal. Anschließend können Sie Dienstprinzipale im Azure-Portal auf dem Blatt Unternehmensanwendungen verwalten.

Während der Anwendungsregistrierung haben Sie die Möglichkeit, den Umleitungs-URI (Uniform Resource Identifier) der Anwendung anzugeben. Der Wert gibt die Position an, an die der Autorisierungsserver den Benutzer umleitet, nachdem die App erfolgreich autorisiert wurde. Der Autorisierungsserver sendet den Code oder das Token an den Umleitungs-URI. Daher ist es wichtig, dass Sie beim App-Registrierungsvorgang den richtigen Ort registrieren.

Was sind Anwendungsberechtigungen?

Anwendungen, die in Microsoft Entra ID integriert werden, folgen einem Autorisierungsmodell, mit dem Sie seine Berechtigungen für andere in Microsoft Entra integrierte Anwendungen und Ressourcen präzise steuern können. Microsoft Entra ID verlässt sich auf das OAuth 2.0-Autorisierungsmodell, um diese Berechtigungen zu implementieren. In OAuth 2.0 sind Berechtigungen in Sätzen angeordnet, die häufig als Bereiche bezeichnet werden.

Als Entwickler fordern Sie die Berechtigungen an, die Ihre Anwendung benötigt, indem Sie eine Berechtigungszeichenfolge als Teil der Konfiguration angeben. Wenn Sie z. B. die Berechtigungszeichenfolge auf „https://graph.microsoft.com/Calendars.Read"“ festlegen, geben Sie an, dass die Anwendung in der Lage sein muss, die Kalender der Benutzer*innen in Microsoft Graph zu lesen. Der Anwendung müssen diese Berechtigungen durch eine Einwilligung erteilt werden, die je nach Umfang dieser Berechtigungen entweder von einem Microsoft Entra-Benutzer oder einem Microsoft Entra-Administrator erteilt werden muss.

Microsoft Entra ID unterstützt zwei Arten von Berechtigungen:

• Delegierte Berechtigungen werden von interaktiven Anwendungen mit einem angemeldeten Benutzer verwendet. Folglich handelt die App im Namen eines angemeldeten Benutzers, wenn sie auf die Zielressource zugreift.
• Anwendungsberechtigungen werden von Anwendungen verwendet, die ohne einen angemeldeten Benutzer ausgeführt werden, z. B. Hintergrunddienste. Für diese Apps ist die Einwilligung eines Administrators erforderlich.

Was sind Anwendungsgeheimnisse?

Für Dienstprinzipale stehen zwei Authentifizierungstypen zur Verfügung:

• Kennwortbasierte Authentifizierung, die auf Anwendungsgeheimnisse zurückgreift, die Sie direkt im Azure-Portal generieren können. Beim Generieren eines Geheimnisses geben Sie dessen Lebensdauer an.
• Zertifikatbasierte Authentifizierung, die sich auf Zertifikate verlässt, die Sie in Microsoft Entra ID hochladen.

Was sind verschiedene Arten von Anwendungsauthentifizierungsszenarien?

Der Authentifizierungsfluss und die entsprechenden Konfigurationsdetails hängen vom Anwendungstyp ab. Zu den gängigen Kategorien von Anwendungstypen gehören:

• Browserbasierte Apps. Dabei handelt es sich um Web-Apps, bei denen Token durch eine im Browser ausgeführte JavaScript- oder TypeScript-Anwendung abgerufen werden. Diese Anwendungen verwenden häufig ein Framework wie Angular, React oder Vue. „MSAL.js“ ist die einzige Microsoft-Authentifizierungsbibliothek, die SPAs unterstützt.
• Öffentliche Clientanwendungen. Dies sind Apps, die immer auf angemeldete Benutzer zurückgreifen, um Token abzurufen. Zu diesen Apps gehören Desktop- und mobile Apps, die Web-APIs im Namen angemeldeter Benutzer aufrufen.
• Vertrauliche Clientanwendungen. Diese rufen Token eigenständig ab. Zu dieser Kategorie gehören Web-Apps, die eine Web-API aufrufen, Web-APIs, die eine andere Web-API aufrufen, Linux-Daemons und Windows-Dienste.

Die ersten beiden Punkte authentifizieren einen Benutzer, während der dritte Punkt nur eine Anwendung oder einen Dienst zwischen dem Benutzer und einem Back-End-Dienst authentifiziert. In diesem Fall hat der Back-End-Dienst keine Informationen über den Endbenutzer, aber er weiß, welche App ihn verwendet. Stellen Sie sich z. B. eine Anwendung vor, die Azure Maps als Back-End-Dienst nutzt. Der Azure Maps-Dienst muss wissen, dass eine autorisierte Anwendung ihn aufruft, um die richtige Abrechnung zu gewährleisten, aber er benötigt keine Informationen über den Endnutzer.

Was ist der Unterschied zwischen Anwendungen mit nur einem Mandanten und mandantenfähigen Microsoft Entra-Anwendungen?

Als Entwickler können Sie Ihre App während der App-Registrierung so konfigurieren, dass sie entweder für einen oder für mehrere Mandanten geeignet ist:

• Einzelinstanzenfähige Apps sind nur in dem Mandanten verfügbar, in dem sie registriert wurden. Dieser wird auch als Basismandant bezeichnet.
• Mandantenfähige Apps sind für Benutzer in ihrem Basismandanten und in anderen Microsoft Entra-Mandanten verfügbar.

Wenn Sie das Azure-Portal für die App-Registrierung verwenden, geben Sie den Mandanten der App an, indem Sie deren „audience“-Eigenschaft auf einen der folgenden Werte festlegen:

• Nur Konten in diesem Verzeichnis. Dies führt zur Konfiguration mit einzelnem Mandanten. Auf diese Weise können Sie jedem Sicherheitsprinzipal in Ihrem Mandanten, einschließlich Gastkonten, Zugriff auf die Anwendung gewähren.
• Konten in einem beliebigen Microsoft Entra-Verzeichnis. Dies führt zu einer mehrinstanzenfähigen Konfiguration. Dadurch können Benutzer außerhalb Ihrer Organisation die Anwendung in ihren jeweiligen Microsoft Entra-Mandanten registrieren.
• Konten in beliebigen Microsoft Entra-Verzeichnissen und persönliche Microsoft-Konten (z. B. Skype, Xbox, Outlook.com). Dies führt auch zu einer mehrinstanzenfähigen Konfiguration, ermöglicht Benutzern mit persönlichen Microsoft-Konten jedoch die Verwendung der App.