Externe Dienste an Entra ID anbinden
Enterprise App, App-Registration und Serviceprinzipal – wo ist der Unterschied ?
Vielen Azure-Admins ist klar, dass die drei in der Überschrift genannten Azure-Entitäten im Kontext der Anbindung externer Dienste und Anwendungen an Entra ID im Zusammenhang stehen. Häufig werden die Begriffe sogar synonym verwendet, was formal aber nicht korrekt ist und auch zu Missverständnissen führt, insbesondere wenn auch Entwickler mit ihren Ansprüchen und ihrer Sicht auf die Dinge involviert sind. Dieser Artikel soll für Aufklärung sorgen.
Da gibt es zunächst „Enterprise Applications“ (Unternehmensanwendungen) und „App Registrations“ (Anwendungsregistrierungen), jeweils mit spezifischer Historie und Daseinsberechtigung. In diesen Kontext gehört auch die Funktion „User Consent“ (Benutzereinwilligung), mit der deine Benutzer quasi externe Dienste für sich buchen und selbständig ins Entra ID integrieren können (siehe Fazit). Dass es hier überhaupt Erklärungsbedarf, aber auch Integrationsmöglichkeiten gibt liegt daran, dass Entra ID als gemeinsamer Identitätsspeicher für alle Microsoft-Cloud-Dienste dient und diese mit Azure (IaaS, PaaS), Microsoft 365 (SaaS) und Dynamics (SaaS) quasi zwangsläufig miteinander integrierbar macht. Zunächst mal halten wir fest, dass Unternehmenswendungen und Anwendungsregistrierungen nicht das Gleiche sind, auch wenn beim Erstellen einer Enterprise App stets eine App Registrierung entsteht und umgekehrt. Leider werfen die entsprechenden Dokumentationen von Drittherstellern etwa zur Integration von SSO z. B. mit Zoom Dropbox oder Salesforce die Dinge ebenfalls oft in einen Topf.
Anwendungsverwaltung
Grundlage der folgenden Erörterungen ist die Anwendungsverwaltung im Microsoft Entra ID. Diese erlaubt das Erstellen, Konfigurieren, Verwalten und Überwachen von Anwendungen in deinem Entra-ID-Mandanten. Ist eine Anwendung erst einmal in einem Entra-Mandanten registriert, können alle ihr zugewiesenen Benutzer sicher darauf zugreifen. Du kannst viele verschiedene Arten von Anwendungen in dein Entra ID registrieren, wie z. B. Webanwendungen, Single-Page-Aps, Web-Apps, Web-APIs, mobile Apps und sogar native Apps. Die Anwendungsverwaltung dient nicht nur dem Entwickeln (App Registration), Hinzufügen und Verbinden von Apps, sondern auch zum Verwalten des Zugriffs darauf (Enterprise Application), zum Schützen der Anwendungen, zum Konfigurieren von Eigenschaften und allgemein der Steuerung und Überwachung von Anwendungen.
Befasst du dich zum ersten Mal mit der Anwendungsverwaltung, besteht der einfachste Weg darin, vorab von Microsoft integrierten Anwendung aus dem Microsoft Entra-Katalog zu registrieren. Du kannst aber wie oben erwähnt auch eigene Anwendung entwickeln und in Microsoft Entra ID registrieren oder eine lokale Anwendung über den Entra ID Anwendungsproxy (https://incas-training.de/blog/wie-du-lokale-apps-deines-unternehmens-mit-hilfe-des-azure-ad-app-proxy-ohne-vpn-fuer-externe-nutzer-verfuegbar-machst/ und eine App Registrierung verfügbar machen, sodass deine Nutzer unter anderen im Portal myapps.microsoft.com auf diese zugreifen können. Folgende Abbildung von Microsoft verdeutlicht die Zusammenhänge:
Enterprise Apps
Beginnen wir mit einer Unternehmensanwendung aus dem Katalog: Klicke dazu im Entra ID auf „Unternehmensanwendungen“ und dann auf „+ Neue Anwendung“. Hier weist Microsoft unmissverständlich darauf hin, worum es sich bei dem Katalog handelt: „Der Microsoft Entra-App-Katalog ist ein Katalog mit Tausenden von Apps, die das Bereitstellen und Konfigurieren des einmaligen Anmeldens (Single Sign-On, SSO) und die automatisierte Benutzerbereitstellung vereinfachen.“
Du kannst dir das so vorstellen, dass es sich bei den Anwendungen im Katalog um Solche handelt, bei denen Microsoft mit den entsprechenden Herstellern (du siehst ja, dass es sich hierbei weitgehend um populäre SaaS-Apps handelt) derart zusammenarbeitet, dass deren Integration in/mit dem EntraID besonders einfach gelingt, weil große Teile der hierfür notwendigen Konfiguration schon bekannt, bzw. entsprechend vorbereitet sind. So „kennt“ Entra ID bei einer Applikation aus dem Katalog beispielsweise „den Weg dorthin“ mit der zugehörigen Anmelde-URL. Für weitere Konfigurationsmaßnahmen, wie z. B. SingleSignOn mit SAML musst du natürlich weitere Schritte unternehmen. Unternehmensanwendungen sind also erst einmal bereits existierende Anwendungen – egal ob von Microsoft (O365) oder einem anderem SaaS-Anbieter (z. B. Salesforce) – die du mit der Funktion „Unternehmensanwendung“ in dein Entra ID integrierst, bzw. sie diesem bekannt machst. Hast du dagegen eine eigene App entwickelt, die webbasierend kommunizieren, bzw. Anmeldeanforderungen via HTTP entgegennehmen kann und möchtest diese an dein Entra ID andocken, dann brauchst du eine App Registrierung.
Nehmen wir an, du möchtest Mitarbeitern eine externe Applikation wie z. B. Zoom zur Verfügung stellen. Zählst du Zoom zu deinen Unternehmensanwendung und möchtest den Zugriff darauf an einen vorhandenen Unternehmenskonto im Entra ID knüpfen und nehmen wir weiter an, dass du den Zugriff auf diese Applikation an ein genehmigtes Unternehmensgerät binden möchtest und möchtest außerdem erreichen, dass deine Nutzer Zoom nicht direkt über die Zoon-URL zugreifen, sondern Zoom aus der Liste der für sie bereitgestellten und genehmigten Unternehmens-Anwendungen im Portal https://myapps.microsoft.com (oder über den O365-App-Launcher) auswählen können sollen, dann musst du Zoom in deinem Entra ID-Mandant als „Unternehmensanwendung“ (Enterprise App) „bekannt“ machen, bzw. in deinen Mandanten einbinden. Ohne diesen Vorgang weiß dein Tenant nichts von Zoom und weiß auch nicht, wo es zu finden ist. Suche also nun im Katalog der Unternehmensanwendungen nach „Zoom“ und klicke dann auf „Erstellen“. Das sollte so aussehen, wie in folgender Abbildung.
Mit der Default-Konfiguration (auf die Einzelheiten gehe ich später ein) sollte die App nun im myapps-Portal derjenigen Benutzer auftauchen, die du im Menüabschnitt „Verwalten“ unter „Benutzer und Gruppen“ der App zugewiesen hast.
Das Erstellen eines Enterprise Apps bedeute zunächst nur, dass dein Benutzer die App in seinem Portal findet, an welchem er sich zuvor mit seinem EntraID-Konto anmelden kann. Damit ist weder SSO, noch bedingter Zugriff oder MFA konfiguriert. Damit ist auch nichts darüber ausgesagt, ob der Nutzer über ein Zoom-Konto verfügt, bzw. ob und wie du die Unternehmensanwendung evtl. dazu bringen kannst, dass erforderliche Zoom-Konto beim ersten Zugriff anzulegen. Vorteil bei einer Unternehmensanwendung aus dem Anwendungskatalog ist aber zweifelsohne, dass Microsoft aus dem Katalog auf ein https://go.microsoft.com/fwlink/?linkid=403225 Schritt-für-Schritt-Tutorial zur Zoom-Integration verweist.
Ziel dieses Beitrags ist wie gesagt nicht das Abarbeiten dieses Tutorials (etwa zur SSO-Integration), sondern das Abgrenzen der Begriffe. Klickst du jetzt im EntraID in die Liste der Unternehmensanwendungen, wirst du dort auch Zoom finden mit einer „Objekt-ID“, einer „Anwendungs-ID“ und einer „Bezeichner-URI (Entitäts-ID)“, dem s. g. „Service-Prinzipal“.
Mit Hilfe des Service- oder Dienstprinzipals kannst du die Unternehmensanwendungen prinzipiell in IAM an Backend-Dienste in Azure berechtigen.
Wir haben jetzt Zoom in unserem Mandanten bekannt gemacht. Das ist die Benutzer-Seite der Konfiguration. Klickst du jetzt in der Unternehmensanwendung auf „Eigenschaften“ findest du hier z. B. die „URL für die Startseite“, das Logo, den Namen oder die „URL für den Benutzerzugriff“, also den so genannten App-Launcher (wenn du beispielsweise nicht möchtest, dass Benutzer die App in ihrem Portal sehen). Außerdem findest du hier noch einmal die „Anwendungs-ID“, die „Objekt-ID“, die „URL zu den Vertragsbedingungen“, die „URL zur Datenschutzerklärung“ und die „Antwort-URL“. Ganz wichtig sind auch die beiden Schiebeschalter „Zuweisung erforderlich“ und „Für Benutzer sichtbar“. Letzterer ist offensichtlich selbsterklärend. Nur wenn er gesetzt ist (was der Default-Einstellung entspricht), taucht die App im myApps-Portal auf; andernfalls ist sie nur über den direkten App-Launcher verfügbar.
Mit „Zuweisung erforderlich“ (was ebenfalls Default ist) ist Folgendes gemeint: belässt du den Schalter auf „Ja“ musst du die App den vorgesehenen Benutzern (oder Diensten oder anderen Apps) zuerst „zuweisen“, bevor sie darauf zugreifen können. Mit „Nein“ können sich alle (berechtigten) Benutzer direkt an der App anmelden, und andere Apps und Dienste können ein Zugriffstoken für diesen Dienst abrufen. Das hat keinen Einfluss darauf, ob die Benutzer auch über ein Konto und/oder eine Lizenz für die App verfügen. Die jeweiligen Voraussetzungen musst du auf der App-Seite schaffen und die sehen bei einer SaaS-Anwendung von Microsoft beispielsweise anders aus, also bei einen 3rd-Party-Anbieter wie Zoom, weshalb ich das Thema SAML oben ja noch einmal angeschnitten habe. Die Option gilt nur für Anwendungen, die SAML, OpenID Connect, OAuth 2.0 oder Webservice-Verbund (WS-Federation) für die Benutzeranmeldung nutzen, sowie Anwendungsproxy-Anwendungen mit aktivierter Microsoft Entra-Vorauthentifizierung (https://incas-training.de/blog/wie-du-lokale-apps-deines-unternehmens-mit-hilfe-des-azure-ad-app-proxy-ohne-vpn-fuer-externe-nutzer-verfuegbar-machst/ ) und Anwendungen oder Dienste, für die andere Anwendungen oder Dienste Zugriffstoken anfordern.
Du kannst mit Unternehmensanwendungen aber auch die „Gegenseite“ (z. B. Zoom) adressieren, sodass wenn einer deiner Benutzer in seinem myapps.microsoft.com-Portal auf Zoom klickt, er ohne weitere zusätzliche Anmeldung zu Zoom weitergeleitet wird.
Dazu musst du wie beschrieben in deiner Unternehmensanwendung eine entsprechende SAML-Konfiguration vornehmen. Du benötigst die erforderlichen Infos von Zoom auf der einen Seite, wie z. B. die „Bezeichner (Entitäts-ID)“, die „Antwort-URL (Assertionsverbraucherdienst-URL)“ und die „Anmelde-URL“ …
… sowie für die Konfiguration von Zoom die entsprechenden Zertifikate vom EntraID, sowie die „URL für Anmeldung“, den „Microsoft Entra-Bezeichner“ und die „Abmelde-URL“:
Möchtest du außerdem, dass das erforderliche Zoom-Konto bei der ersten Anmeldung angelegt, bzw. beim Entfernen eines Entra-Kontos auch das zugehörige Zoom-Konto automatisch gelöscht wird, musst du „in“ der Unternehmensanwendung auf „Bereitstellung“ klicken. Hier begrüßt dich ein „Erste-Schritte“-Assistent und wie üblich findest du hier Links zur Dokumentation, etwa zur „Planung einer Anwendungsbereitstellung“ oder zum „Konfigurieren der automatischen Bereitstellung“.
Im Grunde bezieht sich die hier angedeutete automatische Bereitstellung in erster Linie auf das Erstellen von Benutzeridentitäten und -rollen in den Cloudanwendungen, auf die deine Nutzer Zugriff benötigen. Ergänzend zum Erstellen von Benutzeridentitäten umfasst die automatische Bereitstellung auch das Verwalten oder Entfernen von Benutzeridentitäten, wenn sich der Status oder die Rollen ändern. Folgende Abbildung von Microsoft verdeutlicht den Zusammenhang.
Die Anwendungsbereitstellung sprengt allerdings den Rahmen dieses Beitrags. Wir haben jetzt im Großen und Ganzen konfiguriert, wer (aus deinem Tenant) mit einer Unternehmensanwendung arbeiten kann. Dabei ist quasi als digitale Repräsentation dieser App in deinem Tenant, neben dem zugehörigen Dienst-Prinzipal auch eine App Registration entstanden.
App Registrations
Stell dir diese als eine Art „System-Benutzerkonto“ vor. Du musst hier überhaupt nichts konfigurieren, wenn du nicht magst. Es muss aber ein solches Objekt im Entra ID erstellt werden, weil du eine Anwendung deinem Entra ID hinzugefügt hast. Die App Registration für Zoom stellt damit auch eine eindeutige ID für dieses Anwendung dar.
Bisher hast du eine App Registration erhalten, weil du eine Enterprise App in deinem Tenant erstellt hast. Du kannst auch andersherum vorgehen. Eine App Registration erstellst du immer dann, wenn es um eine App geht, die nicht aus einem vorbereiteten Katalog kommt, weil sie individuell programmiert wurde und irgendwo auf der Welt läuft. Natürlich ist es wieder von Vorteil, wenn es sich dabei um einer moderne OAuth-fähige App handelt. Deren Entwickler muss sich dann nämlich nicht um das Entwickeln einer Authentifizierungslösung kümmern, sondern kann dein Entra ID (also das Verzeichnis, dessen Mitglieder auf die App zugreifen sollen) als Identitätsanbieter-as-a-Service nutzen.
Die App könnte sogar rein lokal in einem hybriden Szenario deines Mandanten laufen, dann käme wieder der Authentication Proxy ins Spiel. Daher muss sich die fremde App in deinem Mandanten registrieren damit dein Tenant weiß, um welche Applikation es geht. Genau das ist eine App Registration.
Beim Erstellen einer App Registration legst du dann fest „wo“ diese verwendet werden kann, also aus welchem Verzeichnis die Nutzer der App stammen dürfen: aus deinem Mandanten, aus einem beliebigen Mandanten oder ein persönliches MS-Konto, bzw. Kombinationen davon. Außerdem kannst du (optional) einen Umleitungs-URI festlegen. Das ist diejenige URI der Fremd-Anwendung, an die die Authentifizierungsantwort (vom Entra ID) gesendet werden soll. Entra ID unterstützt hier wie oben schon erklärt diverse Anwendungs-Plattformen wie „Öffentlicher Client“, Webanwendung oder SPA (Singe-Page-App).
Mit einem Klick auf „Registrieren“ registriert du dann die „fremde“ App in deinem Tenant, womit du wieder eine eindeutige ID, die „Anwendungs-ID (Client“) bekommst.
Das ist dann wieder die gleiche Anwendungs-ID, die du in der gleichnamigen Spalte bei der zeitgleich entstehenden Unternehmensanwendung wiederfindest.
Zurück zur App Registration. Mit einem Klick auf „Endpunkte“ kannst du dir z. B. jetzt sämtliche Microsoft-seitig erstellten Endpunkte für die neue App ansehen, wie u. a. dem „OAuth 2.0-Autorisierungsendpunkt (v2)“, dem „OAuth 2.0-Token-Endpunkt (v2)“ oder das „OpenID Connect-Metadatendokument“ und weitere.
Schließlich kannst du die Berechtigungen konfigurieren, über welche die App in der jeweiligen Umgebung verfügt. Benutzer müssen sich für den Zugriff auf die App zunächst authentifizieren. Aus welchen Tenant diese stammen dürfen, hast du ja eben festgelegt (siehe „Tenant ID“). Nun kannst du im Menü „API-Berechtigungen „festlegen“, welche Berechtigungen die App benötigt, wenn sie von einem deiner Nutzer aufgerufen wird, wie z. B. die Lese-Berechtigung auf das Profil des aufrufenden Nutzers (was dem Default) entspricht.
Du hast hier im Zweifel vollständigen Zugriff auf die Microsoft-Graph-API. Die Microsoft Graph-API ist eine RESTful-Webservice-Schnittstelle, die es Entwicklern ermöglicht, auf Daten und Funktionen in Microsoft 365 zuzugreifen. Sie bietet eine einheitliche Möglichkeit, auf verschiedene Dienste zuzugreifen, ohne dass separate APIs für jedes einzelne Produkt erforderlich sind. So kannst du (bzw. deine App) mit Hilfe der Graph-API auf Benutzerprofile, E-Mails, Kalender, Kontakte, Dateien, Gruppen, Aufgaben und mehr sowie auf Informationen zu Organisationen, Benutzern, Gruppen und Geräten zugreifen.
Damit erlaubt die App-Registrierung deiner Anwendung, auf Ressourcen in Microsoft 365 zuzugreifen, indem sie Berechtigungen über die Microsoft Graph-API erhält. Du setzt hier die Berechtigungen (Scopes), die deine App benötigt, um bestimmte Aktionen auszuführen (z. B. Lesezugriff auf E-Mails oder Schreibzugriff auf Kalender).
Zusammenfassung
Egal über welche Methode du eine Anwendung mit Entra ID verknüpfst, bekommst du neben der Unternehmensanwendung, welche vorrangig der Konfiguration der Nutzer-Sicht dient, auch das „andere Ende“, nämlich die „App-Registration“ mit der „Entwickler“-Perspektive. Du brauchst in jedem Fall beide, auch wenn du je nach Use-Case in der App Registration gar nichts konfigurieren musst. Mit der App Registration verwaltest du die Entwickler-Sicht auf deine App. Hier geht es um Dinge wie APIs oder darum, ob der Zugriff aus deinen eigenen oder einen anderen Tenant erfolgen darf. Beides interessiert den Endanwender im Zweifel aber eher nicht.
Sollen aber auf der anderen Seite Nutzer mit dieser Anwendung arbeiten, brauchst du die Unternehmensanwendung mit welcher du die Sichtweise deiner Benutzer auf die Applikation verwaltest, wie beispielsweise das Einschränken des Zugriffs. Vielleicht möchtest du auch in der eigentlichen Ziel-Anwendung deiner Enterprise Apps (jetzt sind wir wieder bei Zoom) verwalten, wer dort auf was Zugriff hat, wie z. B. einen Ordner, eine Freigabe oder was auch immer.
Damit erklärt sich auch, warum du die Einstellungen für die Benutzereinwilligung („Einwilligungen und Berechtigungen“) auf der Enterprise-App-Seite findest. Hier kannst du schließlich pauschal für alle deine Unternehmensanwendungen steuern, wann Endbenutzer und Gruppenbesitzer die Zustimmung zu Anwendungen erteilen dürfen und wann sie die Überprüfung und Genehmigung durch den Administrator anfordern müssen. Können deine Benutzer Apps den Zugriff auf Daten gewähren, ist es für deine Benutzer einfacher im Self-Service nützliche Anwendungen zu erwerben, allerdings ist das in bestimmten Situationen auch ein Sicherheitsrisiko .
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie