Newsletter vom

Transkript

1 Newsletter vom Security und Single Sign-On Aufgabenstellung Wer Anwendungssysteme entwickelt oder integriert, stößt schnell auf Fragen des Zugriffsschutzes: Die Identität von Benutzern muß überprüft werden und deren Rechte müssen gewahrt sein. Wir sprechen hierbei von Authentifizierung und Autorisierung und fassen beides unter der Überschrift Security zusammen. Besteht eine Anwendungslösung aus mehreren autarken, aber integrierten Komponenten, die z.b. über ein Portal zugänglich gemacht werden, will man i.d.r. zusätzlich erreichen, daß Benutzer sich nur einmal anmelden und dennoch die gemäß ihrer Autorisierung möglichen Funktionen in allen Systemen ohne erneute Anmeldung ausführen können. Diese Funktionalität nennen wir Single Sign-On. Betrachtet man das Feld der in beiden Bereichen relevanten Standards und Technologien, stößt man auf Webserver-Security, Application-Security, J2EE-Security (JAAS), LDAP, den Liberty Alliance Standard für Sigle Sign-On. Alles zusammen stellt den Stand der Technik bei Security und Single Sign-On dar. In unserem Newsletter wollen wir erklären und zeigen, wofür welche der genannten Tools gedacht sind und wie diese zusammenhängend genutzt werden können/sollen. Eine Erläuterung zu den einzelnen Begriffen selbst finden Sie im Anhang. Zur Darstellung der Nutzungsweise in einem homogenen Konzept unterstellen wir ein Beispielszenario, das in dieser oder ähnlicher Form häufig vorkommt. Beispielszenario Eine Anwendungslösung - nennen wir sie für unsere Zwecke schlicht das Portal - integriert drei autarke Subsysteme: 1. Eine SAP-Anwendung, 2. eine Groupware-Komponente (Lotus Notes) und 3. ein in Java/J2EE entwickeltes -System auf Basis der Web-/Applicationserver Tomcat/JBoss. Die Plattform für die Integration der Subsysteme ist ein beliebiger Portalserver wie z.b. JetSpeed, der Enterprise Portal von SAP oder der WepSphere Portal von IBM. Wie die Subsysteme technisch über das Portal integriert sind, lassen wir hier weitgehend unbeachtet. Uns soll stattdessen die Frage interessieren, wodurch Benutzer in die Lage versetzt werden können, mit einer einzigen Anmeldung am Portal auf alle genannten Systeme durchgreifen zu können. Lösung Bitte beachten sie zum besseren Verständnis die zugehörige Skizze. Weiterhin beachten Sie bitte auch, daß wir bewußt ein Szenario resp. eine Lösung ausgewählt haben, bei der sowohl Benutzermapping wie explizites Single Sign-On vorkommen. Zum Ablauf: Für die Portalanmeldung gibt der Benutzer über seinen Browser seinen Benutzernamen und sein Passwort ein. Zunächst wird der Benutzer auf dem Webserver über JAAS authentifiziert. Entsprechend seiner im angebundenen LDAP System hinterlegten Rollen werden Tempelhofer Ufer Berlin Tel. 030/ Seite 1

2 ihm nach seiner Anmeldung die erlaubten Applikationen angeboten. Client Das dem Benutzer angebotene System unterstützt ein explizites Single Sign On der Liberty Alliance. Dafür wird bei der initialen Benutzeranmeldung am Portal eine zusätzliche Anmeldung am Initiale Portalseite im Browser Login Welcome to our Portal Web PortalAppl. SAP SAP Notes Login Portalseite nach Anmeldung Usermapping Logout Lotus Notes Logout Notes Appl. SAP Appl. Appl. JAASRealm PortalLoginModule SSO "Mittel" für SSO im Cookie LDAP Startet der Benutzer aus dem Portal heraus bspw. eine Notes- oder SAP Anwendung, wird auch dieser Aufruf durch den Webserver bearbeitet, indem der Webserver die benötigten Anmeldeinformationen (Name und Passwort) für das Zielsystem in dem Aufruf ergänzt. Das Zielsystem authentifiziert den Benutzer seinerseits gegen das LDAP System, wodurch mit denselben Benutzerdaten gearbeitet wird. Dieses als Benutzermapping bezeichnete Verfahren kann überall dort eingesetzt werden, wo ein autarkes System keine Schnittstelle für ein Single Sign On bietet. Dabei ist es nicht unbedingt notwendig, mit denselben Benutzerdaten zu arbeiten, was allerdings das Benutzermanagement erleichtert. Identity Provider des Single Sign On Systems durchgeführt. Diese Anmeldung erfolgt auf dem Webserver während der eigentlichen Portalanmeldung. Danach stehen dem Benutzer implizit die notwendigen Mittel für den -Applikationsaufruf zur Verfügung. Der Aufruf des s muss daher nicht durch den Webserver modifiziert oder erweitert werden. In unserem Lösungsszenario wird von einer Benutzerrepräsentation in einem LDAP System ausgegangen, auf das alle Applikationen (Notes, SAP und das Portal) zugreifen. Deswegen bezieht auch das Single Sign On System die Daten zur Authentifizierung aus dem zentral eingesetzten LDAP System. Abweichend vom Verfahren des Benutzermappings wird der Benutzer hierbei durch die bei der ersten Anmeldung bereitgestellten "Mittel" durch die anschließend ausgeführten Applikationen identifiziert. Tempelhofer Ufer Berlin Tel. 030/ Seite 2

3 Anhang Webserver Security, z.b. in Tomcat Der Begriff Webserver Security umfasst die Bereiche der Authentifizierung und Autorisierung. Durch die Authentifizierung wird die wahre Identität einer Person oder eines Programms an Hand eines bestimmten Merkmals, z.b. dem Fingerabdruck, überprüft. Die Authentifizierung kann auf vier verschiedenen Wegen erfolgen: Besitz (z.b. Schlüssel, Karte) Wissen (z.b. Passwort) Sein (z.b. Biometrische Merkmale) Können (z.b. elektronische Unterschrift) Autorisierung ist die Zuweisung und Überprüfung von Zugriffsrechten für die Nutzung von Ressourcen durch Benutzer oder Programme. Die Autorisierung erfolgt meist nach einer erfolgreichen Authentifizierung. Beide Bereiche werden innerhalb eines Webservers i.d.r. in Form eines Dienstes bereitgestellt. Tomcat verwendet dafür sog. Realms (Bereiche). Die aktuelle Version liefert spezialisierte Realms für den Zugriff auf RDBMS-, LDAP-, und JAA-Systeme. Über einen Realm wird nach einem Login die Identität eines Benutzers überprüft, anschließend dessen Berechtigungen ausgelesen und diese dann der Anwendung über den Webserverkontext zur Verfügung gestellt. Die Verwendung eines konkreten Realms wird in der Systemkonfiguration bekannt gegeben. Weitere applikationsspezifische Konfigurationseinträge bestimmen, welche Seiten durch welche Benutzergruppen ausgeführt werden dürfen und welche Login Methode zu verwenden ist. Die Bekanntgabe der zu schützenden Seiten erfolgt über eine oder mehrere Pfadangaben (z.b. /security/*, alle Seiten unterhalb des Pfades security erfordern einen Login). Die zu berechtigten Benutzer werden über Rollen deklariert. Die Login Methode beschreibt, ob eine individuelle Loginseite (FORM) oder ein Standard Loginfenster des Browsers (BASIC) zur Benutzeranmeldung verwendet wird. Der über die Konfigurationsdateien beschriebene Zugriffsschutz wird als deklarative Sicherheit bezeichnet. Dieser Zugriffschutz ist sehr grobgranular, da er nur den Zugriff auf ganze Seiten reglementiert. Ergänzend dazu gibt es die programmatische Sicherheit, die innerhalb der Programmlogik verwendet werden kann. Der Realm bietet eine Schnittstelle, mit der vor Ausführung einer Verarbeitung die Rolle eines Benutzers überprüft und somit eine konditionale Verarbeitung ermöglicht wird. Application Security, z.b. in JBoss Hierbei handelt es sich um die Beschreibung und Verwendung von Security Mechanismen im Umfeld von Enterprise Java Beans (EJB). Wie bei der Webserver Security wird auch hier zwischen deklarativer und programmatischer Sicherheit unterschieden. Der deklarative Bereich erfolgt wiederum in einer Konfigurationsdatei. Dort werden Rollen definiert und diese anschließend den EJBs und deren Methoden zugewiesen. Für die programmatische Sicherheit steht dem Entwickler eine Schnittstelle über den Kontext des Application s zur Verfügung. Über diese Schnittstelle lässt sich analog zu einem Realm erfragen, ob ein Benutzer im Besitz einer bestimmten Rolle ist. Da JBoss keine eigene Servlet Engine bereitstellt, wird häufig die Kombination mit Tomcat oder Jetty für dessen Betrieb gewählt. Damit beide Systeme ein einheitliches Login Modul verwenden, wird abweichend vom Stand Alone Webserver Betrieb das Login Modul innerhalb von JBoss über eine Loginkonfigurationsdatei oder alternativ über eine MBean definiert. Tempelhofer Ufer Berlin Tel. 030/ Seite 3

4 J2EE Security mit JAAS Das Java Authentication und Autorisation System (JAAS) ist die Java Implementierung des aus dem Unixumfeld bekannten Pluggable Authentication Module (PAM). Es ist seit der SDK Version 1.3.x verfügbar. Zur Authentifizierung wird ein zu verwendendes Loginsystem außerhalb der Applikation über eine Konfigurationsdatei definiert. Ein konkretes Loginsystem wird über spezielle Login Module zum Lesen reiner Datenquellen wie RDBMS oder LDAP Systeme, oder auch für eigenständige Sicherheitssysteme wie Kerberos gekapselt. Bei der Verwendung von JAAS arbeitet der Anwendungsentwickler fast ausschließlich mit einem Subject. Ein Subject ist die Abstraktion eines Benutzers, Dienstes oder Systems. Das Subject wird bei der Authentifizierung aus dem speziell angebundenen Login Module über einen Loginkontext gefüllt. Die konkrete Benutzeridentität und dessen Rollen werden über einen Principal ausgeprägt und dessen Instanzen dem Subject nach erfolgreicher Authentifizierung zugeordnet. Diese sehr flache Abbildung eines Rollen-Rechte-Systems reicht in der Praxis häufig nicht aus, um komplexe Beziehungen abzubilden. Die semantische Ausprägung eines Principals muss deshalb außerhalb des Sicherheitssystems auf einer eigenen Systemebene erfolgen. Innerhalb eines Subjects werden Rollen, Gruppen und Identitäten auf einer Hierarchiestufe über Principals abgebildet, obwohl sie semantisch womöglich in unterschiedlichen Abhängigkeiten und Beziehungen zueinander stehen. Der Anwendungsdeployer muss dies für die Deklaration der für die Autorisation benötigten Rollen entsprechend beachten. Das Subject bietet Methoden zu Realisierung einer programmatischen Sicherheit. Über diese Methoden wird überprüft, ob der Benutzer über die notwendigen Berechtigungen zur Verwendung von Ressourcen verfügt. Berechtigungen werden gemäß der Java Security Architecture in einer sog. Policy Datei außerhalb der Applikation deklariert. Innerhalb dieser Datei werden die Rechte mit den vorgesehenen Rollen verknüpft. Für die Aktivierung der Berechtigungsprüfung, wird die Policy Datei dem Security Manager der Java Virtuellen Maschine (JVM) übergeben. Die Verwendung des Security Managers in Verbindung mit der Policy Datei wird beim Starten des Web- bzw. Application s über Startparameter konfiguriert und aktiviert. LDAP Bei dem Lightweight Directory Access Protocol handelt es sich um ein Protokoll für den Zugriff auf Directory Services. Die aktuelle Protokollversion ist V3. Ein Directory Service bildet seine Daten in einer baumartigen Struktur ab. Diese Struktur eignet sich hervorragend für schnelle lesende und suchende Zugriffe. Ein Directory Service implementiert keine transaktionale Sicherheit. Dies wirkt sich zusätzlich unterstützend auf die Performance der Zugriffe aus. In einem Directory Service können neben den bekannten Standarddatentypen auch individuelle Datentypen und -strukturen über Schemata definiert werden. Schemata können die Daten in einem Directory Service validieren. Directory Services bieten von Haus aus Synchronisations- und Replikationsmechanismen, wodurch sie sich besonders gut für einen verteilten Einsatz eignen. Der global eingesetzte Domain Name Service (DNS) basiert bspw. auf einem international verteilten Directory Service. Die Verwendung von Namensräumen garantiert dabei eine einheitliche Datensicht. Die Datenstrukturen sollten in einem Directory Service relativ flach gehalten werden, um die Zugriffe zu optimieren. Ein typischer Einsatzbereich für einen Directory Service ist die Speicherung von Mitarbeiter- und Kundeninformationen. Viele Hersteller bieten ihrerseits Schnittstellen zu Directory Services an (z.b. Lotus Notes, Outlook, Tomcat, JBoss, etc). Dadurch hat sich LDAP zum de facto Standard entwickelt. Tempelhofer Ufer Berlin Tel. 030/ Seite 4

5 Single Sign On, z.b. analog der Liberty Alliance Ein Single Sign On (SSO) ist eine einmalige Benutzeranmeldung an einem System. Bei der Einbeziehung nachfolgender autarker Systeme, die ihrerseits eine Authentifizierung erfordern, führt ein Single Sign On eine transparente Benutzeranmeldung durch. Es können grundsätzlich zwei verschiedene Herangehensweisen zur Realisierung eines SSOs unterschieden werden: 1. Im unsauberen Fall kennt das führende System (z.b. ein Portal) für einen Benutzer sämtliche seiner Repräsentationen (Benutzernamen und Passworte) in den nachgeordneten Systemen. Wird eine Verarbeitung in einem nachgeordneten System notwendig, meldet das führende System den Benutzer dort parallel an. Diese Vorgehensweise basiert technisch betrachtet auf einem Benutzermapping und benötigt ein explizites Benutzermanagement. Über ein solches Benutzermanagement müssen zum einen die Benutzerangaben für die nachfolgenden Systeme verwaltet werden. Zum anderen sind darüber die Verbindungen in nachgelagerte Systeme zu verwalten. Das Management umfasst bspw. terminierte Verbindungen, die für den Benutzer für erneute Zugriffe transparent wieder aufgebaut werden müssen. Es betrifft aber auch eine systemweite Abmeldung, die aus Sicherheitsgründen ratsam ist und darüber hinaus Systemressourcen schont. 2. Ein reiner SSO sieht hingegen vor, dass ein Benutzer nach der Authentifizierung am führenden System für Anmeldungen an nachgelagerten Systemen keine weitere bzw. erneute Angabe von Benutzernamen und Passworten erfordert. Bei diesem Ansatz ist eine homogene Authentifizierungsschicht in allen beteiligten Systemen notwendig. Im Microsoft Umfeld wurde dazu die Passport Initiative gegründet. Das Pendant im Java Umfeld kommt aus dem Umfeld der Liberty Alliance, in der sich viele namhafte Hersteller engagieren (SAP, Novell, Sun, etc). Eine Open Source Implementierung von der für das Webserverumfeld liegt in einer Version 1.1 für Tomcat, Bea Weblogic, Websphere, Orion (eingesetzt im Oracle 9iAS), JBoss und weiteren n vor. Diese Implementierung wurde maßgeblich von Hewlett Packard und Nokia gefördert. Für die Implementierung eines reinen SSO bietet die heterogene Anwendungslandschaft aktuell leider noch keine durchgängige Realisierung à la Passport bzw. Liberty Alliance. Dies liegt an den fehlenden Schnittstellen und Technologien innerhalb der Standardsoftwareprodukte. Die aktuellen Standards im Web- und Application Umfeld ermöglichen es jedoch, mit relativ geringem Aufwand, Standardprodukte über ein Benutzermapping einzubinden. Um dieses Mapping abzubilden, bietet sich die Einbeziehung eines LDAP Systems an, da dieses von einer Vielzahl bestehender Standardprodukte unterstützt wird. Ein LDAP System kann dazu verwendet werden, die Benutzerrepräsentationen im Optimum auf nur eine Ausprägung in der gesamten Anwendungs- und Systemlandschaft zu reduzieren. Diese eine Ausprägung kann dann durchgängig in allen beteiligten Systemen verwendet werden, was wiederum das Benutzermanagement vereinfacht. Tempelhofer Ufer Berlin Tel. 030/ Seite 5