Grundlegende Konzepte

Artikel
03/19/2009

Kapitel 7: Anwendungen

Veröffentlicht: 11. Mai 2004 | Aktualisiert: 26. Jun 2006

Anwendungen spielen für Strategien zur Identitäts- und Zugriffsverwaltung eine wichtige Rolle. Von Anwendungen werden digitale Identitätsdaten zum Autorisieren beansprucht und Berechtigungen analysiert, aufgrund derer Zugriff auf Ressourcen gewährt wird. Beim Auswählen oder Entwickeln von Anwendungen ist unbedingt darauf zu achten, dass die Anwendungen in die Identitäts- und Zugriffsverwaltungsstruktur passen.

Anwendungen fallen gewöhnlich in eine von zwei Kategorien:

Drittanbieteranwendungen, serienmäßig hergestellte Anwendungen oder kommerzielle Anwendungen wie Microsoft® Exchange Server 2003.
Benutzerdefinierte oder betriebsinterne Anwendungen, die von Entwicklern für die Organisation geschrieben wurden.

Unabhängig davon, ob eine Anwendung speziell entwickelt oder serienmäßig hergestellt wurde, ist zu gewährleisten, dass sie auf effektive Weise in die Identitäts- und Zugriffsverwaltungsstruktur der Organisation integriert wird. Je nach Art der zu integrierenden Anwendung sind jedoch unterschiedliche Kriterien zu berücksichtigen.

Ob sich eine Anwendung leicht oder schwer in die Identitäts- und Zugriffsverwaltungsplattform integrieren lässt, hängt von der Architektur der Anwendung und den Mechanismen ab, die zum Identifizieren von Benutzern verwendet werden. Microsoft empfiehlt, Anwendungen zu identifizieren, zu klassifizieren und ihre Funktionalitäts- und Infrastrukturabhängigkeiten zu bestimmen. Sollte eine Anwendung mit der Identitäts- und Zugriffsverwaltungsplattform Ihrer Organisation nicht kompatibel sein, sind entweder an der Anwendung oder an der Infrastruktur Änderungen vorzunehmen.

Hinweis Aus Sicht der Anwendungsentwicklung ist es wichtig, dass von Anwendungen weder ihre eigenen Identitätsspeicher noch Sicherheitsprotokolle (zum Authentifizieren, Autorisieren und Überprüfen) oder Datenschutzmechanismen erfunden und implementiert werden sollen.

In den folgenden Abschnitten dieses Kapitels werden empfohlene Methoden zum Integrieren von Anwendungen in die Microsoft Identity and Access Management-Plattform behandelt. Diese Informationen stellen auch die Grundlage dar, um die Techniken zum Entwickeln, Testen und Bereitstellen von identitätsbewussten Anwendungen im Detail zu besprechen. Im Artikel „Entwickeln identitätsbewusster Anwendungen“, der Bestandteil dieser Serie ist, wird genauer beschrieben, welche Schritte von Anwendungsarchitekten und -entwicklern zum Integrieren von Anwendungen in die Infrastruktur durchzuführen sind.

Auf dieser Seite

Auswählen von Anwendungen
Entwickeln von Anwendungen

Auswählen von Anwendungen

Beim Auswählen einer Anwendung legen IT-Manager häufig großen Wert darauf, dass sie über die erforderlichen Funktionen verfügt. Leider macht man sich dabei häufig keine Gedanken darüber, wie sich diese Anwendung in das Netzwerk integrieren lässt. Dies ist besonders im Hinblick auf die Identitätsverwaltung von Bedeutung.

Mit Drittanbieteranwendungen können Benutzer folgendermaßen identifiziert werden:

Integrieren in den primären Verzeichnisdienst der Organisation
Verknüpfen mit dem primären Verzeichnisdienst über eine standardbasierte Verbindung
Authentifizieren an einen anderen Verzeichnisdienst
Verwenden eines dedizierten Identitätsspeichers

Exchange Server 2003 ist ein Beispiel für eine Anwendung, die sich vollständig in einen Verzeichnisdienst integrieren lässt. Exchange erweitert das Verzeichnisdienstschema von Microsoft Active Directory® und fügt dann Benutzerkonten in Active Directory Postfachattribute hinzu. Im Gegensatz zu Exchange 5.5 haben Exchange 2000 Server und Exchange Server 2003 keine eigene Verzeichnisdatenbank. Am leichtesten lässt sich die Anwendungsidentitätsverwaltung durch eine vollständige Integration in einen Verzeichnisdienst implementieren.

Einige Anwendungen lassen sich nicht vollständig in einen Verzeichnisdienst integrieren, mit ihnen ist jedoch über standardbasierte Verbindungen das Authentifizieren von Benutzern an ein Verzeichnis möglich. Dabei handelt es sich beispielsweise um Anwendungen, die das Authentifizierungsprotokoll von Kerberos 5 zum Authentifizieren an Active Directory verwenden können. SAP R/3 ist eine solche Anwendung und Teil der fiktiven Contoso-Umgebung, auf die bereits in anderen Artikeln dieser Serie verwiesen wurde.

Die Authentifizierung kann von Anwendungen auch an einen Verzeichnisdienst erfolgen, bei dem es sich nicht um das primäre Verzeichnis der Organisation handelt. Dies ist nicht ideal, da dadurch das primäre Verzeichnis mit dem von der Anwendung verwendeten Verzeichnis synchronisiert werden muss. Mit Metaverzeichnisprodukten wie Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 SP1) kann diese Synchronisierung über Verwaltungsagenten erfolgen, die an die meisten gebräuchlichen Identitätsspeicher angeschlossen sind.

Am ungünstigsten ist es, wenn die Anwendung über einen dedizierten proprietären Identitätsspeicher verfügt und kein Tool vorhanden ist, mit dem die Identitätsdaten in ein von MIIS 2003 SP1 unterstütztes Format importiert bzw. exportiert werden können. In diesem ganz besonderen Fall lässt sich der Identitätsspeicher einer Anwendung unter Umständen nicht mithilfe von MIIS 2003 SP1 mit dem primären Verzeichnisdienst synchronisieren. Dann kann man Identitäten im Identitätsspeicher der Anwendung nur noch manuell verwalten, was nicht nur kostspielig ist, sondern auch leicht zu Fehlern führt.

Entwickeln von Anwendungen

Wenn Sie Anwendungen intern entwickeln, sind von Ihren Anwendungsarchitekten und -entwicklern drei grundlegende Vorgehensweisen zu berücksichtigen:

Anwendungsintegration: Hier wird bestimmt, ob eine Integration in oder eine Interoperabilität mit der Infrastruktur gewünscht wird.
Identitätsfluss: Hier wird eine geeignete Kombination aus den drei grundlegenden Modellen für die Front-End- und die Back-End-Authentifizierung ausgewählt.
Autorisierung: Hier wird eine Kombination aus den zwei grundlegenden Autorisierungsmodellen ausgewählt.

Durch die in diesen drei Bereichen ausgewählten Optionen wird bestimmt, welche Anwendung Entwickler zum Authentifizieren, Autorisieren und Überprüfen implementieren müssen. Bei einer gut integrierten Anwendung ist fast kein identitätsbewusster Code zu implementieren, da bereits alle Arbeiten von der zugrunde liegenden Infrastruktur ausgeführt werden.

Für die Anwendungsintegration sind die Aspekte wichtig, die bereits im Abschnitt „Auswählen von Anwendungen“ behandelt wurden.

Aktivieren des Identitätsflusses

Für den Fluss der Identität des authentifizierten Benutzers in verteilten Umgebungen (so genannter Identitätsfluss) gibt es drei unterschiedliche Modelle. Dabei handelt es sich um folgende Modelle:

Identitätswechsel/Delegierung
Vertrauenswürdiges Subsystem
Anmeldedatenzuordnung

Verwenden des Modells „Identitätswechsel/Delegierung“

Durch Identitätswechsel kann ein Servervorgang unter Verwendung der Sicherheitsanmeldeinformationen des Clients ausgeführt werden. Wenn vom Server ein Identitätswechsel für den Client durchgeführt wird, werden für sämtliche vom Server durchgeführte Vorgänge die Anmeldeinformationen des Clients verwendet. Durch den Identitätswechsel kann der Server jedoch nicht für den Client auf Remoteressourcen zugreifen. Dazu ist die Delegierung erforderlich. Die Delegierung ist leistungsstärker, und durch sie kann der Servervorgang Anrufe an andere Computer tätigen und gleichzeitig als Client fungieren.

Verwenden des Modells „Vertrauenswürdiges Subsystem“

Bei diesem Modell wird vom Middle-Tier-Dienst für den Zugriff auf Downstreamdienste und -ressourcen eine feste Identität verwendet. Der Sicherheitskontext des ursprünglichen Anrufers fließt nicht durch den Dienst auf der Betriebssystemebene, obwohl die Anwendung die Option hat, den Identitätsfluss für den ursprünglichen Anrufer auf Anwendungsebene durchzuführen. Unter Umständen ist dies zum Erfüllen der Anforderungen für die Back-End-Überprüfung oder zum Unterstützen des Datenzugriffs und der Autorisierung pro Benutzer erforderlich.

Der Name des Modells bezieht sich darauf, dass der Downstreamdienst (möglicherweise eine Datenbank) dem Upstreamdienst beim Autorisieren von Anrufern vertraut.

Verwenden des Modells „Anmeldedatenzuordnung“

Beim Modell für Anmeldedatenzuordnung wird ein Satz an Anmeldedaten in einer Zuordnungstabelle einem anderen Satz zugeordnet. Die zugeordneten Anmeldedaten können dann zum Erstellen einer neuen Verbindung zu einem anderen System verwendet werden. Es gibt zwei Arten dieses Modells für Anmeldedatenzuordnung: Bei einer werden Anmeldedaten direkt zugeordnet, und bei der anderen erfolgt die Zuordnung auf indirekte Weise, d. h., es werden so genannte Tickets vergeben, die später gegen Anmeldedaten eingetauscht werden. Sie können das Modell für Anmeldedatenzuordnung verwenden, wenn vom Zielsystem das Authentifizierungsprotokoll von Kerberos 5 nicht unterstützt oder Active Directory nicht als Identitätsspeicher verwendet wird.

Implementieren der Autorisierung

Nachdem der Benutzer von der Anwendung identifiziert wurde, ist zu steuern, worauf dieser Benutzer durch die Autorisierung zugreifen soll. Dies sind die beiden Anwendungsautorisierungsmodelle:

Zugriffssteuerungsliste (Access Control List, ACL)
Rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC)

Verwenden des Modells „Zugriffssteuerungsliste“

Beim ACL-Modell wird eine Ressource (z. B. ein Datei-, Ordner-, Drucker- oder Verzeichnisdienstobjekt) mithilfe einer ACL geschützt. Dabei handelt es sich um eine Liste von Benutzern und Gruppen sowie um die Berechtigungen (sowohl zum Zulassen als auch zum Verweigern) für die einzelnen Benutzer oder Gruppen. Wenn ein Benutzer auf die Ressource zugreifen möchte, werden die Zugriffsberechtigungen dieses Benutzers sowie die Zugriffsberechtigungen all der Gruppen, denen der Benutzer angehört, überprüft. Je nachdem, über welche Zugriffsberechtigungen der Benutzer verfügt, wird ihm dann der Zugriff gewährt oder verweigert.

Das ACL-Modell eignet sich hervorragend für gut definierte beständige Objekte, nicht jedoch für bestimmte Umgebungen wie LOB-Anwendungen (Line-Of-Business) oder Webanwendungen. Für diese Anwendungsarten sowie für Workflowanwendungen und vorübergehende Objekte empfiehlt es sich, ein anderes Modell zu verwenden.

Verwenden des Modells „Rollenbasierte Zugriffssteuerung“

Bei RBAC wird das Rollenkonzept verwendet. Gewöhnlich handelt es sich bei einer Rolle um den Titel einer Stelle wie „Manager“, „Kassierer“ oder „Verkaufsleiter“. Bei RBAC werden diesen Rollen Anwendungsberechtigungen zugeordnet, damit die Verwaltung der Zugriffssteuerung nach der Rolle des Benutzers erfolgen kann.

Von RBAC wird dann die Rollenmitgliedschaft eines Benutzers in Anwendungsberechtigungen umgewandelt. Da die Berechtigungen auf Rollenebene gewährt werden, können Berechtigungen in Frage gestellt und für die Rolle geändert werden, ohne dass die spezifischen Ressourcen untersucht werden müssen.

Nachdem Administratoren die Rollen erstellt und diesen Rollen Berechtigungen zugeordnet haben, sollten kaum mehr Änderungen an Rollen oder Berechtigungen erforderlich sein. Die einzigen Änderungen bestehen darin, diesen Rollen Benutzer (oder Gruppen) zuzuordnen.

Im Artikel „Entwickeln identitätsbewusster ASP.NET-Anwendungen“, der Bestandteil dieser Serie ist, wird genauer beschrieben, welche Schritte von Anwendungsarchitekten und -entwicklern zum Integrieren von Anwendungen in die Infrastruktur durchzuführen sind.