Datenquellen anbinden
Mit dem Code zur Authentifizierung können Sie nun in Ihrer Anwendung auf weitere Ressourcen zugreifen. Ein beliebtes Beispiel: Microsoft Graph. Alle Endpunkte von Graph sind Entra-integriert und lassen sich mithilfe des "scopes"-Parameters anfragen. Danach erhalten Sie dann ein Access Token. Selbiges händigen sie mit Ihrer Anfrage an Graph aus – und zwar dann, wenn Sie die Webanfrage an Graph stellen, als Teil des Headers in "Authorization".

Mit diesem Muster sind alle Ressourcen im Benutzerkontext erreichbar, die in Entra ID integriert sind. Wenn Sie Datenquellen haben, die nicht mit moderner Authentifizierung arbeiten können oder nicht in Entra ID integriert wurden, obliegt es ihrer Anwendung, weitere Schnittstellen oder Daten abzubilden und die App-zu-Datenquelle- oder "on-behalf-of"-Authentifizierung für einen Benutzer anzusteuern.

Lädt die zu modernisierende Anwendung nach dem Login benutzerspezifische Konfigurationen nach, müssen Sie die Umsetzung von Entra-Token und Loginnamen womöglich übersetzen. Manche Anwendungen sind etwa gewohnt, eine Windows-AD-ObjektID oder einen Security Identifier (SID) aus dem Kerberos-Token zu nutzen.

Die Informationen legen Sie dann in der eigenen Konfigurationsdatenbank ab. Sie werden nach dem Login geladen. In so einem Fall sind Änderungen bei der Entra-Integration notwendig: Aus den Claims im Token, das die dann modernisierte Anwendung nutzt, erhält die Anwendung die On-Premises-SID nicht mehr. Hier bestehen nun drei Möglichkeiten:

1. Sie bringen der Anwendung bei, über eine Lookup-Tabelle den UPN in eine SID/ObjektID zu übersetzen, die in der Konfigurationsdatenbank bekannt ist.
2. Sie konvertieren die ObjektIDs und SIDs in der Datenbank und überführen Sie in die ObjektIDs, die Entra ID für die jeweiligen Benutzer kennt – und extrahieren die Entra-ObjektID für Benutzer dann aus dem "id_token" oder
3. Sie liefern die Windows-AD-ObjektID oder SID in einem Azure-AD-Erweiterungsattribut nach, dessen Wert Sie dann als Claim nutzen.

Ähnliches gilt für Anwendungen, die Berechtigungen anhand von Benutzernamen-zu-Berechtigungen-Paaren in eigenen Datenbanken speichern. Sie können die Benutzernamen, sollten Sie den UPN nicht nutzen oder weiterverwenden können, natürlich übersetzen. Sind Sie an einem moderneren Ansatz interessiert, sollten Sie die Berechtigungsvergabe und -kontrolle in Ihrer App dahingehend ändern, dass Sie auf Rollendefinitionen vertrauen, die Ihnen der Identity Provider übergibt.

Rollenzuweisungen und Mitgliedschaft prüfen
Viele Anwendungen überprüfen gegen eine Datenbank in SQL, LDAP oder im Windows-AD, ob Mitarbeiter berechtigt sind, die App generell oder Teile der App – etwa kritische Reports oder Kundendaten – zu benutzen. Diese In-App-Berechtigungen sind im Idealfall in einer Datenbank zentralisiert, könnten aber auch pro Anwendung in der anwendungsnahen Datenbank stehen.

Migrieren Sie die Anwendung, müssen Sie die Berechtigungen ebenfalls umziehen. Mit klassischem Lift-and-Shift-Ansatz bedeutet das, dass die Datenbank in der Cloud läuft. Können Sie sich eine Modernisierung leisten, teilt der Identity Provider Informationen zu Berechtigungen, etwa Gruppen- und Rollenzugehörigkeiten.

Ist die Anwendung Entra-integriert, lässt sich Microsoft Graph nach den Gruppenmitgliedschaften eines Benutzers befragen. Ist etwa der Benutzer Mitglied der Berechtigungsgruppe "FINANCE_WEB_KUNDEN_REPORTS", darf er auf die entsprechenden Berichte zugreifen, andernfalls nicht. Die Graph-Anfrage gestalten Sie dann ähnlich, wie Sie das von LDAP oder SQL kennen – Sie betrachten die Berechtigungsgruppe und suchen nach dem aktuellen Benutzer:

GET https://graph.microsoft.com/ v1.0/groups/b2438beb-00ce-442580b7-5e87a3ecf038/members/?$filter=id eq '065c5cb5-9bb7-4e76ae40-25127df92307'

Oder Sie haben den aktuellen Benutzer und fragen an, ob eine der wichtigen Gruppen in der Mitgliedschaft des Benutzers liegt:

GET https://graph.microsoft.com/ v1.0/users/065c5cb5-9bb7-4e76ae40-25127df92307/memberOf/?$filter=id eq 'b2438beb-00ce-442580b7-5e87a3ecf038'

Die Beispielanfragen arbeiten mit den jeweiligen Objekt-IDs aus Entra IDmit denen Graph effizient suchen kann. Sind die Berechtigungsdetails in einem anderen Attribut oder einer Profildekoration am Benutzerobjekt hinterlegt, kann die Anwendung Graph nach dem jeweiligen Benutzerattribut fragen und danach entscheiden.

Noch eleganter ist, wenn Sie der Anwendung beibringen können, relevante Berechtigungsinformationen aus den SAML- oder Access-Tokens vom Identity Provider auszulesen. In Entra ID können Sie die Berechtigungen als Rollen- oder Gruppenclaims in das Token packen, das die Anwendung dann erhält und auswerten kann. Die Rollen- und Gruppenmitgliedschaft pflegen Sie in diesem Fall entweder in Entra ID, über ein Tool mit Graph-Anschluss an Entra ID oder in Ihrem Windows-AD, wenn Sie die Gruppe danach nach Entra ID synchronisieren. Die Gruppen lassen Sie dann entweder im "groups"- oder "roles"-Claim im Token niederschreiben.

Sie müssen auch nicht alle Gruppen in die Claims für die Anwendung stecken. Sie können vielmehr eine Filterung für die relevanten Gruppen vornehmen, damit jede App nur die Gruppenmitgliedschaften sehen und auswerten kann, die sie benötigt. Sind die Rollendefinitionen in der Anwendung schon vorbestimmt, wie etwa "Kundenreports_Lesen" und "Kundenreports_Schreiben", definieren und hinterlegen Sie diese Rollen in Entra ID einfach am Anwendungsobjekt. Wenn Sie Benutzern dann bestimmte Tätigkeiten zuteilen wollen, nehmen Sie eine Benutzer-zu-Rollen-Zuweisung vor.

Fazit
Anwendungen in Azure zu betreiben, kann Kosten senken und Verwaltungsaufwand reduzieren. Wenn Sie die Applikationen tiefergreifend analysieren und, was ihre Architektur betrifft, für die Cloud optimieren, sollten Sie Zero Trust und Anmeldekomfort für die Mitarbeiter im Kopf behalten. Wenn Mitarbeiter einfacher via SSO oder neuerdings von zu Hause mit einem vertrauten Gerät Anwendungen nutzen können, ist das auch ein Zugewinn für die IT-Abteilung.

ln/Florian Herzog

Im ersten Teil der Workshopserie schilderten wir, wie Sie die zu veröffentlichende Anwendung genau unter die Lupe nehmen. Im zweiten Teil haben wir  beschrieben, wie Sie beim Migrieren von Anwendungen Conditional Access profitieren und was es dabei mit der Microsoft Authentication Library auf sich hat.