Mit dem Novell Access Manager 3 hat Novell eine Lösung für das Access Management auf den Markt gebracht, die das bisherige Produkt iChain ablöst und funktional wesentlich erweitert. Auch wenn einige Teilfunktionen von iChain Eingang in den Novell Access Manager (NAM) 3 gefunden haben, handelt es sich doch im Kern um ein neues Produkt. Das zeigt sich schon bei der Architektur, die sich grundlegend vom bisherigen iChain-Produkt, aber auch von anderen Novell-Lösungen und den Wettbewerbsprodukten im Access-Management-Markt unterscheidet.
Der Name deutet bereits auf die Kernfunktionalität, das Access-Management hin. Beim Access-Management geht es darum, dass Zugriffe – vor allem auf Webanwendungen – von einer zentralen Anwendung authentifiziert und autorisiert werden. Unterstützt werden aber auch andere Anwendungen, soweit diese über die verfügbaren Schnittstellen mit dem Access Manager integriert werden und diesen als zentrale Authentifizierungsplattform nutzen.
Neuerungen in Version 3
Neben dieser Basisfunktionalität gibt es eine Reihe weiterer wichtiger Funktionen insbesondere für das Single Sign-On. Ein solches Single Sign-On wird zunächst einmal natürlich schon durch die Web Access Management-Funktionalität erreicht, weil man sich darüber einmalig für verschiedene Anwendungen authentifizieren kann. Zusätzlich werden von dem Produkt aber auch die SAML- und Liberty Alliance-Standards für die Identity Federation unterstützt. Damit können Vertrauensstellungen mit anderen Systemen realisiert und Bestätigungen zu einer erfolgreichen Authentifizierung in standardisierter Form übertragen werden.
Ein weiterer wichtiger Funktionsbereich ist das SSL VPN (Virtual Private Network), über das sichere Verbindungen zu anderen Standorten aufgebaut werden können. Erwähnenswert ist auch die Unterstützung für unterschiedliche Authentifizierungsmechanismen, die allerdings überraschenderweise nicht auf NMAS basiert, sowie die Unterstützung für ein rollenbasierendes Zugriffsmanagement. Die Berechtigungen dafür, wer in welcher Form auf Informationen zugreifen darf, werden also über Rollen gesteuert.
Die Dienste
Der NAM 3 stellt eine Reihe von Diensten für Anwendungsumgebungen bereit. Die zentralen Aufgaben sind die Authentifizierung und Autorisierung. Eine Authentifizierung ist bei allen Funktionen des NAM 3 zwingend, um den Benutzer den Zugriff auf Anwendungen zu geben. Die Authentifizierung wird über den Identity Manager zentral durchgeführt.
Für die Authentifizierung werden unterschiedliche Mechanismen wie Benutzername/Kennwort, Token-basierende Verfahren in Verbindung mit RADIUS und digitale Zertifikate nach dem X.509-Standard unterstützt. Welcher Mechanismus verwendet wird, hängt davon ab, wie die Anforderungen der weiteren Komponenten sind. Für jede Nutzungsform des NAM 3 kann gezielt in einem „Vertrag“ spezifiziert werden, welche Authentifizierungsanforderungen bestehen. Es ist also durchaus möglich, dass für unterschiedliche Komponenten des NAM 3 und für den Zugriff auf unterschiedliche Backend-Anwendungen mit unterschiedlichen Authentifizierungsverfahren gearbeitet wird.
Die Benutzerinformationen selbst können in unterschiedlichen Verzeichnissen liegen. Es muss sich nicht zwingend um ein eDirectory handeln. Auch das Active Directory und der Sun Directory Server werden standardmäßig unterstützt.
Die Identity-Federation-Mechanismen
Wie weiter oben schon erwähnt, werden als spezielle Variante für die Authentifizierung auch die Identity-Federation-Mechanismen unterstützt. In diesem Fall erfolgt die Authentifizierung durch den Identity-Server, die Autorisierung aber durch ein externes System, das als sogenannter Service Provider arbeitet. Der Austausch der Informationen erfolgt auf Basis der weiter oben genannten Standards.
Wichtig sind dabei zwei Punkte:
-
Mithilfe der Identity Federation können Informationen auch zwischen Systemen unterschiedlicher Hersteller ausgetauscht werden, soweit diese die entsprechenden Standards unterstützen. Der derzeit am besten geeignete Mechanismus ist SAML 2.0. In einem Interoperabilitätstest, den die Analysten von Kuppinger Cole + Partner im Herbst 2006 durchgeführt haben, hat sich dieses Verfahren als das am besten geeignete gezeigt.
-
Novell arbeitet für die Kommunikation zwischen allen funktionalen Komponenten des NAM 3 ebenfalls mit Federation-Standards. Der Identity-Server fungiert damit also immer als Identity Provider im Federation-Modell, während die anderen Module als Service-Provider arbeiten und der Authentifizierung des NAM 3 vertrauen. Diese modulare Struktur erleichtert die Anpassung und Erweiterung des NAM 3 und das Zusammenspiel mit Komponenten von Drittanbietern.
Basierend auf der Authentifizierung erfolgt die Autorisierung. Dabei steuert der Access Manager mithilfe von Richtlinien, wer in welcher Form auf Anwendungen zugreifen darf – oder eben nicht. Der richtlinienbasierende Ansatz ist nicht überraschend. Für die Steuerung der Berechtigungen werden die beim Identity-Server definierten Rollen verwendet.
Der Dienst Identity Injection
Als weiteren wichtigen Dienst gibt es die Identity Injection. Damit können Informationen aus einem Verzeichnis angefordert und über das Access-Gateway an eine Anwendung weitergeleitet werden. Das Access-Gateway kann diese Informationen in unterschiedlicher Form übergeben:
-
HTML-Header
-
Abfrage-String
-
Basic Authentication Headers
-
Form Fill, also das automatische Ausfüllen von Formularen mit definierten Daten
Dieser Mechanismus wurde bei iChain – allerdings mit geringerer Flexibilität – als Object Level Access Control (OLAC) bezeichnet. Mit den so übermittelten Informationen kann ein Backend-System beispielsweise die Personalisierung von Informationen oder eine weitere Autorisierung durchführen. Außerdem kann so oft auch auf Webanwendungen zugegriffen werden, die eine spezielle Authentifizierung erfordern, weil die Informationen vom NAM 3 übergeben werden können.
Komponenten und Mechanismen
Um diese Dienste bereitstellen zu können, werden verschiedene Komponenten und Mechanismen benötigt. Die zentrale Rolle spielen die schon erwähnten Identity-Server und Access-Gateways.
Identity-Server
Identity-Server sind dafür zuständig, die Authentifizierung durchzuführen und auf Anforderung weitere Identitätsdaten bereitzustellen. Diese Komponenten sind auch die Identity-Provider aus Sicht der Federation-Standards. Neben den schon genannten Funktionen sind einige weitere Aspekte erwähnenswert:
Der Identity-Server unterstützt auch das Federated Provisioning oder Account Provisioning. Dabei werden bei der Übergabe von Informationen zu bisher noch nicht angelegten Benutzern automatisch Benutzerkonten erzeugt. Allerdings wird dafür – mangels eines offenen Standards – ein proprietäres Verfahren verwendet, sodass diese Funktionalität nur zwischen verschiedenen Implementierungen des NAM 3 einsetzbar ist.
Über Mappings von Attributen können Schlüsselwörter aus Dokumenten, die den Liberty-Alliance-Standards entsprechen, auf LDAP-Attribute abgebildet werden.
Neben dem Single Sign-On wird auch das Single Logout unterstützt, also die korrekte Abmeldung bei den Systemen, an denen ein Single Sign-On erfolgt ist.
Die Identity-Server können zu einem Cluster zusammengefasst werden. Gleiches gilt übrigens auch für die Access-Gateways. Die Unterstützung für das Clustering ist beim Einsatzbereich des NAM zwingend. Wenn die Authentifizierung und Autorisierung der Zugriffe von Kunden für Websites durchgeführt werden soll, braucht man eine hoch skalierbare Lösung.
Access-Gateway
Die zweite wichtige Komponente neben dem Identity-Server ist das Access-Gateway. Über dieses Modul laufen die eigentlichen Zugriffe auf Anwendungen. Genau genommen ist es auch der typische Einstiegspunkt für den Anwender, weil sein Zugriff zunächst beim Access-Gateway ankommt. Von diesem erfolgt zunächst eine Weiterleitung der Anforderung an den Identity-Server, bevor der eigentliche Zugriff durchgeführt werden kann.
Das Access-Gateway bietet auch Caching-Mechanismen, um die Last auf den Zielanwendungen so gering wie möglich zu halten. Allerdings funktioniert das natürlich nur bei statischen Seiten oder statischen Elementen von Websites, kann aber die Last doch deutlich verringern. Das Access-Gateway wird übrigens in Form einer sogenanntn Soft Appliance geliefert, muss also nicht von Beginn an installiert und konfiguriert werden. Vielmehr wird eine Basisinstallation nur noch an die speziellen Anforderungen angepasst.
SSL-VPNs und J2EE-Agents
Die dritte Komponente ist das Modul für SSLVPNs. Damit werden Zugriffe von Anwendungen unterstützt, die nicht über HTTP arbeiten. Auch für diese kann die Authentifizierung und Autorisierung übernommen werden. Dieser Dienst wird nur auf Linux-Basis angeboten. Auf der Seite des Clients wird mit einem ActiveX-Control oder einem Java-Applet gearbeitet.
J2EE-Agents
Während der Zugriff auf Webanwendungen mit den Standardfunktionen des Access-Gateways sehr flexibel gesteuert werden kann, wird für andere Anwendungen noch eine spezielle Schnittstelle benötigt. Diese wird in Form der J2EEAgents geliefert, die es aktuell für JBoss und IBM WebSphere gibt. Diese Agenten sind sozusagen der Mittler zwischen den Enterprise-Anwendungen und dem NAM 3. Sie basieren auf den Standards JAAS (Java Authentication and Authorization) und JACC (Java Authorization Contract for Contracts). Damit lassen sie sich von bestehenden J2EE-Anwendungen aus, die diese Standards ebenfalls unterstützen, einfach nutzen.
Richtlinien
Eine wichtige Methode für die Nutzung des NAM 3 sind die Richtlinien. Richtlinien werden für die Autorisierung verwendet. Dabei wird festgelegt, in welchem Zusammenhang Informationen im Identity Manager mit den aktiven Rollen für einen Benutzer stehen. Je nach Attributen werden also unterschiedliche Rollen zugewiesen.
Diese Rollen werden wiederum verwendet, um die Autorisierung durchzuführen. Die Autorisierung kann wiederum auf sehr unterschiedlichen Ebenen erfolgen. Im einfachsten Fall kann man den Zugriff auf eine Website erlauben oder verweigern, aber auch die Nutzung einzelner Seiten gezielt steuern. In der Praxis wird man meist irgendwo in der Mitte liegen.
Interessant ist dabei, dass Rollen auch an Java-Anwendungen weitergeleitet werden können, um dort genutzt zu werden – ebenso wie man die Informationen über die weiter oben beschriebenen Mechanismen auch an Websites übergeben kann.
Zertifikatsmanagement und Auditing
Eine weitere Komponente ist das Zertifikatsmanagement. Da die gesamte Kommunikation auf Federation-Mechanismen basiert und diese wiederum digitale Signaturen und die Verschlüsselung nutzen, um die Kommunikation zu sichern, können die Zertifikate auch über den NAM 3 verwaltet werden.
Auditing
Schließlich wird – wenig überraschend – auch das Auditing von Ereignissen und deren Protokollierung unterstützt. Mit dem NAM 3 wird eine Basisversion von Novell Audit geliefert. Mit der Vollversion von Novell Audit lassen sich auch anwendungsübergreifende Analysen durchführen.
Die Schnittstellen
Die Verwaltung erfolgt über eine spezielle Verwaltungskonsole. Dabei handelt es sich um eine Variante des Novell iManager, die allerdings nicht mit anderen iManager-Installationen integriert werden kann.
In der Übersicht fühlt man sich etwas an den Novell Identity Manager erinnert, weil es auch dort ein übergreifendes Diagramm mit dem Zusammenspiel der verschiedenen Komponenten gibt (Bild 1).
Dass das Produkt nicht in einer iManager-Infrastruktur gemeinsam mit anderen Komponenten wie dem Identity Manager verwaltet werden kann, ist etwas bedauerlich. Man darf gespannt sein, ob sich das mit zukünftigen Releases des iManager oder des NAM 3 noch ändert. Benutzern steht zusätzlich eine Portalanwendung zur Verfügung, über die sie sich an Anwendungen authentifizieren, bestimmte Aspekte der Identity Federation selbst verwalten und ihre Profile administrieren können. (mja)
Der Autor: Martin Kuppinger ist freier Journalist, Autor von über 40 IT-Fachbüchern und Unternehmensberater (www.kuppinger.de). Außerdem ist er Gründer und Senior Partner bei Kuppinger Cole + Partner, Analysten für digitale ID und Identity Management (www.kuppingercole.de).