EJB – Sicherheit Nach J2EE-Spezifikation 1.4

Seminar IT-Sicherheit WS 02/03, Prof.Löhr

Jan Steinkraus (steinkra@inf.fu-berlin.de)

3514457

Einleitung / J2EE-Architektur Diese Ausarbeitung bezieht sich allgemein auf die Vorgaben der J2EE-Spezifikation und orientiert sich exemplarisch an der Server-Beispielimplementierung des J2EE-SDK von Sun. Die Java 2 Enterprise Edition (J2EE) von Sun beinhaltet eine Spezifikation für Verteilte Geschäftsapplikationen. Darin ist neben den Komponenten der Geschäftsapplikation, den Enterprise JavaBeans (EJB), auch die Infrastruktur zu deren Ausführung spezifiziert. Die J2EE-Spezifikation zielt auf die Implementierung von mehrschichtigen Client/Server Anwendungen ab (multi-tier client/server applications). Mit EJB werden Geschäftsprozesse und Geschäftskomponenten modelliert (z.B. Kunde, Auftrag, Rechnung).

Die Infrastruktur beinhaltet Applikations-Server mit sogenannten Containern, in denen die EJB ausgeführt werden. Der Server bzw. der Container interagiert mit den Unternehmens-Systemressourcen (z.B. Datenbank) und übernimmt auch die Interaktion mit verteilten Beans in anderen Servern und Maschinen. Weiterhin kontrolliert er die Ausführung von selbstdefinierten Transaktionen und handhabt Sicherheitseinstellungen. J2EE-Server bieten also typische Middleware-Techniken an, um eine einfache Komponenten-Programmierung zu ermöglichen. Es wird auf Programmiererseite von der technischen Sicht des Gesamtsystems abstrahiert und als Schnittstelle dazu der Container angeboten. EJB-Programmierer sollen sich größtenteils mit der Lösung der Geschäftsabläufe befassen und wiederverwendbare Komponenten produzieren. Das Idealbild ist, daß diese Komponenten dann in jeglichen nach J2EE spezifizierten Servern laufen sollen. Weiterhin sind als Teil der Infrastruktur auch die Kommunikationsformen der EJB mit den Containern und die Kommunikation zwischen den Containern vorgeschrieben. Ebenso ist die Schnittstelle des Servers zu Clients und Ressourcen weitgehend reglementiert. Anhand der J2EE-Spezifikation können Firmen eigene Server implementieren und zertifizieren lassen. Kompatibilität zu J2EE kann z.B. mit der J2EE Compatibility Test Suite (CTS) überprüft werden (aktuell nur für Version 1.2 verfügbar). Anbieter solcher Server sind z.B. BEA, Sun, IBM, Jboss (Open Source) etc. Es gibt prinzipiell drei Arten von Enterprise Java Beans:

• Session Bean - Führt Anfragen eines Clients während einer Session aus und beschäftigt sich ausschließlich mit diesem Client. Es existiert nur für die Zeit der Session (nicht persistent). Es kann Schritte und Daten der Interaktion zwischenspeichern. Beispiel: Einkaufswagen, interakt. Kontoverwaltung.

• Entity Bean - Eine Geschäftslogik-Komponente, die persistent gehalten werden muß. (meist mithilfe von Datenbanken über JDBC). Beispiel: Kunden, Auftrag, Produkte... Auf sie kann über Schlüssel zugegriffen werden. Entity Beans können in Relation zu mehreren anderen Beans stehen und erlauben parallelen Zugriff.

• Message-Driven Bean – Wird nicht über Interfaces angesprochen, sondern reagiert

auf Nachrichten der JMS-API. Das Bean wird nur beim Eintreffen einer Nachricht aktiv. Somit werden Serverressourcen gespart. Beispiel: Die Buchung einer Reise löst in einem Session-Bean eine Nachricht aus, die ein Message-Driven Bean empfängt und dann eigenständig Vorgänge wie Rechnung schicken, Reservierung im Hotel, Flugbuchung usw. ausführt.

Die Spezifikation sieht prinzipiell 3 Beteiligte an dem Lebenszyklus eines EJB (3 players in EJB-lifecycle).

• Den „bean provider/developer“ der das Bean programmiert, den • „application assembler“ der aus Beans eine Anwendung zusammenstellt und den

• „bean deployer“, der das Bean auf einem Server ausführt.

Diese drei Beteiligten haben verschiedene Aufgabengebiete in Bezug auf die Systemsicherheit. Sie kommunizieren sicherheitstechnische Einstellungen und Rollenzuweisungen über den deployment descriptor, eine XML-Datei, die zur Konfigurierung einer J2EE-Anwendung dient. Um Einstellungen übersichtlich vornehmen zu können, ist ein tool zur Bearbeitung des deployment descriptor nach Spezifikation zwingend vorgeschrieben. Dieses „deployment tool” soll die Einführung und Administration eines rollenbasierten Zugriffsschutzes über eine Benutzerschnittstelle ermöglichen.

Multi-Tier Architektur / Die Sicherung der Tier

Ein System, das nach der J2EE-Spezifikation implementiert wurde, lässt sich in drei verschiedene Schichten einteilen, die sogenannten Tier. Was diese Tier symbolisieren und wo die sicherheitskritischen Aspekte liegen, sei hier vorab kurz zusammengefasst:

Client-Tier

Der Client-Tier symbolisiert die Seite des Systembenutzers. Systembenutzer können z.B. Kunden, Angestellte, Administratoren oder auch andere Java- / CORBA-Anwendungen sein. Diese Benutzer/Klienten können auf das System entweder über ein Browserinterface (Applets oder serverseitig generiertes HTML) oder über eine (Java-)Applikation zugreifen. Besonderes Augenmerk gilt hier der Kommunikation zwischen Web-/Applicationclient und dem J2EE-Server sowie deren initialen Authentisierung.

Mid-tier Der Midtier symbolisiert die Applikation, das System und dessen Infrastruktur auf dem J2EE-Server. Sicherheitskritische Punkte wären hier die Umsetzung eines rollenbasierten Zugriffsschutzes, das Zusammenspiel der „3 players“, die besondere Behandlung von Message-Driven Beans, sowie die Container-Container-Kommunikation bei verteilten Systemen.

EIS/Legacy-Tier Der Legacy-Tier repräsentiert die an das J2EE-System angeschlossenen firmeninternen Ressourcen wie etwa Datenbanken o.Ä. Die Kommunikation des Containers mit diesen Systemen und die Authentisierung des Containers sind hier zu beachten.

Mid-Tier Sicherheit Der grundlegende Gedanke von J2EE-Anwendungen ist es, sowenig wie möglich programmatische Sicherheit in die Beans zu codieren, sondern vielmehr deklarative Sicherheitseinstellungen über über den Server tätigen zu können. Während ältere J2EE-Spezifikationen die Sicherheit nur am Rande behandelten, wurde sie seit der Version 2.0 zunehmends genauer reglementiert. Zentrale Themen und Neuerungen sind hierbei die Authentisierung von Klienten und sichere Kommunikationsformen zwischen Klient und Server. Weiterhin ist die Kommunikation zwischen Containern zunehmends gesichert worden. Die Umsetzung eines rollenbasierten Zugriffsschutzes wird durch die „Security Identity propagation“ innerhalb des Systems ermöglicht, also dem Weiterreichen der Identität eines EJB-aufrufenden Client. Seit der EJB-Spezifikation Version 2.1 ist die Application-Client-Authentisierung über den Java Authentication and Authorisation Service (JAAS) möglich. Ein Client wird bei seiner Anmeldung am System zunächst als ein unidentifiziertes Subject angesehen. Nach erfolgreicher Authentisierung werden diesem Client-Subject (u.A. mehrere) sogenannte Principals und Credentials zugeordnet. Principals werden über das java.security.Principal-Interface implementiert und assoziieren das Client-Subject mit einem Benutzernamen oder –konto. Beispiel für ein Principal wäre z.B „Herr Meier,...“ oder „meier@inf...“. Credentials sind Objekte, die sicherheitsrelevante Daten wie etwa ein Kerberos-Ticket oder Zertifikate des Clients speichern. Einfachste Möglichkeit wäre das Loginpasswort o.Ä. darin abzulegen. Folgendes Diagramm veranschaulicht die Zuordnung von Principals und Credentials an ein Subject:

Principals werden später wiederum bestimmten Rollen zugeordnet, die Teil der umzusetzenden Sicherheitspolitik des Systems sind. Man spricht dann von „principal-to-role-mapping“. Es ist nach Spezifikation für J2EE-Server erforderlich, ein tool zur Verfügung zu stellen, das dieses Mapping übernimmt (z.B durch Abgleich mit einer Datenbank). Innerhalb des Systems werden die Principals und mit ihnen die aufgesetzten Rollen von Aufruf zu Aufruf der EJB weiterpropagiert und sind auch über den EJBContext innerhalb des EJB-Codes jederzeit abfragbar. Dazu später mehr. Eine unverschlüsselte Datenübertragung kommt besonders für Geschäftsanwendungen heutzutage selten noch in Frage, da ansonsten eine vertrauliche Übermittlung von Kunden- und Logindaten nicht gewährleistet werden kann. Es sind also sichere Übertragungsverfahren erforderlich, wobei SSL (Secure Sockets Layer) die zentrale Rolle bei J2EE –konformen Anwendungen spielt. SSL bietet bekanntlich die Möglichkeit zur Datenverschlüsselung und Überprüfung der Datenintegrität (über eine TCP/IP-Verbindung). Ebenfalls ist damit die Authentisierung von Servern gegenüber Clients und optionale Client Authentisierung möglich. Die Spezifikation besagt, daß für den Betrieb von SSL ein X.509 Server Certificate im Server eingebettet werden muss. Das ist auch exemplarisch bei der Beispiel-Serverimplementierung von Sun der Fall. Dort wird das mitgelieferte „keytool“ dazu verwendet, Zertifikate zur Signierung durch Certificate Authorities (CA) vorzubereiten bzw. bereits ausgestellte Server-Zertifikate zu verwalten. Um den Server etwa vor Attacken aus dem Internet (Denial of Service usw.) schützen zu können, ist es ratsam intelligente Paketfilter einzusetzen, also den Server hinter einer Firewall zu betreiben. An dieser Stelle sei bemerkt, daß die Sicherung von netzverfügbaren Ressourcen ein Kapitel für sich ist. Deshalb wird hier im Allgemeinen auch nur auf die für J2EE speziellen Sicherungsmechanismen eingegangen. Sichere Netzwerkarchitekturen für Unternehmen zu beschreiben würde den Rahmen sprengen. Es stehen Mechanismen bereit, die es erlauben, authentisierten Klienten Rollen zuzuordnen und diese durch das gesamte System zu propagieren. Der Container kann „automatisch“ prüfen, ob eine Rolle oder Identität überhaupt Zugriff auf ein bestimmtes Bean hat, dazu ist nicht unbedingt eine Abfrage innerhalb des Bean-Codes notwendig. Bei der J2EE-Architektur ist es möglich, für jedes EJB anzugeben, welche Rolle zum Aufruf welcher Methode berechtigt ist. Es ist also eine feinkörnige Abstimmung auf die Funktionalität der einzelnen EJB möglich. Ein aufrufendes Subject kann einerseits direkt eine Client-Anwendung sein, aber auch ein anderes EJB. Vom Client aufgerufene EJB propagieren dessen Identität und zugeordnete Rollen zu anderen EJB, die im Zuge der Programmausführung aufgerufen werden.

Als Option steht allerdings noch die Möglichkeit offen, EJB immer die selbe Rolle propagieren zu lassen, unabhängig vom aufrufenden Subject. Ein Bean kann z.B immer die Rolle „Guest“ propagieren, um etwa den niedrigsten Sicherheitslevel einzunehmen, egal ob der Aufrufende nun in die Rolle „Customer“ oder „Admin“ fällt. Die Einstellung geschieht über ein „runAs“-Element im deployment-descriptor. Hier ist natürlich Vorsicht geboten, da das betroffene EJB bei entsprechender Einstellung auch in sehr privilegierten Rollen agieren kann. Darüber den Überblick zu behalten ist Aufgabe des Assemblers und Deployers gleichermassen. Da die Rollen evtl. über verteilte Server propagiert werden, muss der Deployer laut Spezifikation sichergehen, ein „trust relationship“ zwischen den Servern der Applikation zu etablieren. Dies kann mithilfe von SSL mutual authentication geschehen. Hierbei sind die Optionen sehr abhängig von der Implementierung und nicht eindeutig vorgegeben. J2EE empfiehlt also im Grunde nur ein Konzept, aber nicht unbedingt die Modalitäten zu dessen Umsetzung. Das Sicherheitskonzept steht und fällt mit den „trust relationships“. Ist unter den vertrauten Servern ein Kompromittierender, können Beans die auf ihm laufen mithilfe von „runAs“ im Grunde in alle Rollen schlüpfen. Der Deployer wird jedoch schwer darauf achten, daß solche Szenarien nicht entstehen und wahrscheinlich werden konkrete Serverimplementierungen für dieses „Problem“ Lösungen anbieten. Der folgende Ausschnitt ist aus einem deployment descriptor entnommen. Als Beispiel dient hier ein EJB “CustomerAccount”, das mittels eines “runAs“-Elements immer die Rolle „staff“ weiterpropagiert: ... <enterprise-beans>

... <session>

<ejb-name>CustomerAccount</ejb-name> ... <security-identity>

<runAs-specified-identity> <role-name>staff</role-name>

</runAs-specified-identity> </security-identity> ...

</session> ...

</enterprise-beans> ...

3 players Wie Rollen überhaupt allgemein festgelegt werden, wird im folgenden Abschnitt anhand der einzelnen Aufgabenbereiche der „3 players in EJB lifecycle“ veranschaulicht. Die Bearbeitungsschritte unterscheiden sich u.A. in der Art der Deklarierung im deployment descriptor.

Bean Provider (EJB-Entwickler)

Der Bean Provider, also derjenige der die EJB programmiert, soll „so wenig wie möglich“ mit Sicherheitsfragen belangt werden. Programmierer sollen sich größtenteils auf die Erstellung von wiederverwendbaren Komponenten und die Umsetzung von Geschäftsabläufen konzentrieren. Ein Programmierer von EJB kann auch im Entwicklungsstadium noch wenig über das spätere Gesamtsystem und seine Sicherheitspolitik wissen. Das soll er auch nicht, da es erwünscht ist, die jeweilige Sicherheitspolitik nicht hart im Code einzubetten, sondern später über den Container zu kontrollieren und konfigurieren zu können. Auf seinem Weg bis hin zur Ausführung durchläuft ein EJB laut Schema auch schließlich noch die Hände von assembler und deployer. In bestimmten Fällen ist es jedoch garnicht möglich, auf die „programmatische Sicherheit“ zu verzichten. Soll es beispielsweise möglich sein, Aktionen bzw. Methodenaufrufe nur abhängig von der Tageszeit oder abhängig von einem Konto-Betrag durchzuführen, muss das innerhalb des Beans implementiert werden. Die zur Überprüfung dieser Bedingungen nötigen Werte werden schließlich erst zur Laufzeit bestimmt und verändert. (Um solche im Programm verankerten Abfragen dennoch später über den Server manipulierbar zu machen, kann man über den Container bestimmte Variablen zur Laufzeit einlesen lassen. Das Weiterreichen dieser Werte kann z.B über das EJBContext-Objekt geschehen. Dazu sind entsprechende Eingaben im deploytool möglich.) Wird nun dennoch programmatische Sicherheit gewünscht, ist es dem Programmierer innerhalb des EJB-Codes möglich, die Rollen des aufrufenden Subjects zu ermitteln. Er kann dann im Code den Zugriff direkt und dynamisch kontrollieren. Über das vom Container bereitgestellte EJBContext-Objekt (javax.ejb.EJBContext) für EJB bzw. HttpServletRequest-Objekt für beispielsweise JSP, können die folgenden Methoden aufgerufen werden:

• ejbContext.getCallerPrincipal() • ejbContext.isCallerInRole(“Kunde”); • httpServletRequest.isUserInRole(“Kunde”); • httpServletRequest.getUserPrincipal()

Die Methode getCallerPrincipal() bzw. getUserPrincipal() hat als Rückgabewert dabei ein Principal-Objekt, das die Identität des Aufrufenden Subjects beinhaltet. Mithilfe von isCallerInRole(String role) bzw. isUserInRole(String role) ist die direkte Abfrage der Rollenzugehörigkeit möglich (Rückgabewerte sind boolean). Da vom Standpunkt des Programmierers aus noch keine systemweiten Rollen eingeführt wurden, kann der Programmierer über den deployment-descriptor eigene Rollen einführen. Diese Rollen sollten größtenteils allgemein und „logisch“ auf eine Geschäftsstruktur angewendet werden können. So wird es höchstwahrscheinlich in einem Bank-EJB das Kontendaten abruft, eine Rolle „Kunde“ bzw. „Angestellter“ oder „Admin“ geben. Es müssen dazu im deployment-descriptor sogenannte Rollenreferenzen (<security-role-ref>) eingeführt werden. Der Entwickler erstellt damit vorerst logische Rollen, die später vom Assembler den tatsächlichen Rollen im System zugeordnet werden. Folgender Ausschnitt aus einem deployment descriptor zeigt exemplarisch die Einführung einer logischen Rolle „admin“. ... <security-role-ref> <description> This role encompasses the administrators of the on-line shopping company. </description> <role-name>admin</role-name> </security-role-ref> ... Später ist es möglich, die letztendlichen Rollen des Systems im deployment-descriptor auf diese logischen Rollen des Programmierers abzubilden. Dazu mehr im nächsten Abschnitt.

Application Assembler

Der Applicationassembler hat die Aufgabe das System aus den EJB-Komponenten zusammenzustellen und verkaufsfertig zu konfigurieren. In Bezug auf Sicherheit deklariert er auf den späteren Einsatzzweck zugeschnittene Rollen. Diese setzen, wie oben schon bemerkt, dann u.A. auf den Rollen des providers auf und müssen auch diesen zugeordnet werden. Dazu muss er einen Überblick über die im Code eingebetteten Abhängigkeiten Bescheid wissen. Ohne Zuordnung der Rollenreferenzen auf Rollen des Systems sind diese Rollenreferenzen ohne Bedeutung. Diese erzwungene Zuordnung von logischen Rollen auf die tatsächlich verwendeten Rollen verhindert, daß der Programmierer nur ihm bekannten Rollen einführen kann. Eine geheim deklarierte Rolle wie etwa „Programmierer“ müsste also auch vom Assembler/Deployer deklariert und abgesegnet werden, um im System wirken zu können. Somit wird diese Art von programmatischen Hintertürchen vermieden. Weiterhin muss der Assembler festlegen, welche spezifischen Methoden der einzelnen EJB von welcher Rolle aufgerufen werden dürfen. Dies geschieht mittels method permissions. Diese Permissions werden für jedes Bean einzeln vergeben. Alle diese Schritte manifestiert der Assembler wieder im deployment-descriptor. Zunächst ein Auszug aus einem deployment-descriptor, der die Einführung von System-Rollen veranschaulicht. Besonderes Augenmerk gilt dem fett gedruckten Abschnitt. Diese Rolle „staff“ wird später der im obigen Beispiel eingeführten Rollenreferenz „admin“ des Programmierers zugeordnet. ... <assembly-descriptor>

<security-role> <description>

This role includes the members of the on-line business who are allowed to access the special products application. Only users who have the role member can access the special products.

</description> <role-name>member</role-name> </security-role>

<security-role> <description>

This role includes the customers of the on-linebusiness. This role is only allowed to access the regular products.

</description> <role-name>customer</role-name>

</security-role><security-role>

<description> This role should be assigned to the personnel of the on-line store who are authorized to perform administrative functions.

</description> <role-name>staff</role-name>

</security-role> ...

</assembly-descriptor> ...

Folgendes snippet zeigt nun die Zuordnung von Rollenreferenzen auf System-Rollen. Es wird dazu ein <role-link>-Element benutzt, das der Deklarierung des Programmierers hinzugefügt wird: ... <enterprise-beans> ...

<entity> <ejb-name>CustomerAccount</ejb-name> <ejb-class>com.account.CustomerAccountBean</ejb-class> ... <security-role-ref>

<description> This role encompasses the administrators of the on-line shopping company. The role reference has been linked to the staff role.

</description> <role-name>admin</role-name> <role-link>staff</role-link>

</security-role-ref> ...

</entity> ...

</enterprise-beans> … Der nächste Auszug zeigt die Einführung der method-permissions für ein einzelnes Bean. Zu den jeweiligen Rollen (customer, staff) werden die für sie erlaubten Methoden deklariert. Innerhalb des <method-name>-Elements können die folgenden drei Werte stehen:

• Der Name der erlaubten Methode • Der Name und eventuelle Parameter, um sie eindeutig zu identifizieren • Ein *, um alle Methoden für eine Rolle freizugeben

... <method-permission>

<role-name>customer</role-name> <method>

<ejb-name>CustomerAccount</ejb-name> <method-name>*</method-name>

</method> </method-permission> <method-permission>

<role-name>staff</role-name> <method>

<ejb-name>CustomerAccount</ejb-name> <method-name>listOrder</method-name>

</method> <method>

<ejb-name>CustomerAccount</ejb-name> <method-name>deleteOrder</method-name>

</method> <method>

<ejb-name>CustomerAccount</ejb-name> <method-name>placeOrder</method-name>

</method> </method-permission> …

Deployer Der Deployer ist zunächst auf eine gute Spezifikation des Assemblers angewiesen, um sich in dessen Rollensystem und mit den Sicherheitseinstellungen zurechtzufinden. Er sollte auch nur Produkte von Firmen einsetzen, die ihm als vertrauenswürdig erscheinen. Um eigene Rollen zum System hinzufügen zu können, muss er unter Umständen auch über Rollenreferenzen des Programmierers Bescheid wissen, um diese nicht zu vergessen und um diese korrekt auf seine neuen Rollen abzubilden. Es ist Aufgabe des Deployers, das auf seine Bedürfnisse angepasste Sicherheitssystem zu administrieren Es muss in diesem Stadium, d.h. während der Ausführung durch den deployer, eine letztendliche Zuordnung von Benutzern bzw. Benutzergruppen auf die Rollen festgelegt werden. Zu diesem Zweck erfordert es die J2EE-Spezifikation, daß mit einer Serverimplementierung bestimmte Tools zur Verwaltung mitgeliefert werden. So u.A. für die allgemeine Administration des Rollensystems und der Abbildung von Benutzern und Benutzergruppen auf diese Rollen.

Principal-to-Role-Mapping Diese Zuordnung von Subject-Identitäten auf Rollen wird als Principal-to-Role-Mapping bezeichnet. Die Spezifikation besagt, daß ein Principal-to-Role-Mapping jeweils nur für eine einzelne Applikation innerhalb des Containers gilt. Das bedeutet aus technischer Sicht, das ein Mapping nur für ein Applikations-jar-File gültig ist. Für jedes einzelne jar-File müssen Principals also separat auf Rollen abgebildet werden. Das liegt daran, daß ein deployment-descriptor nicht applikationsübergreifend lesbar ist, sondern nur für die Applikation gilt, in der er enthalten ist. In ihm werden schließlich die Rollen deklariert, die für jede Anwendung anders sein können. Darum müssen diese für jede Anwendung unterschiedlichen Rollen notwendigerweise jedesmal individuell „gemappt“ werden. Damit läßt sich als Nebeneffekt aber auch die weitere Einteilung von Benutzergruppen umsetzen: Angenommen auf einem Server laufen zwei Applikationen für jeweils verschiedene Geschäftsabteilungen. Angestellte der einzelnen Abteilung werden per Principal-to-Role-Mapping nur für ihre Abteilungs-Applikation zugelassen. Diese grobe Einteilung vermeidet ein unnötiges Aufblähen der Rollenstruktur: Um zwischen gleichen Tätigkeitsbereichen, aber verschiedenen Abteilungen differenzieren zu können, müssten Rollen eingeführt werden, die eine Unterscheidung nach Abteilungen ermöglicht. (etwa Spielzeugabteilungs-Admin vs. Drogerieabteilungs-Admin). Das kann durch das separate Mapping von Angestellten auf die einzelnen Applikationen vermieden werden. Es müssen bei diesem Beispiel somit keine neuen Rollen eingeführt werden, da jede Rolle (in diesem Falle dann Admin) nur für ihre zugehörige Applikation berechtigt ist. Im Server des J2EE-SDK gibt es im deploytool folgende Möglichkeiten:

• Es lässt sich für jedes Bean ziemlich einfach und übersichtlich festlegen, ob die Identität des Aufrufenden, oder mittels „runAs“ eine andere Rolle propagiert wird. Die im System bekannten (also im deployment-descriptor deklarierten) Rollen lassen sich dazu über ein Pulldown-Menü selektieren.

• Die method permissions lassen sich in drei Kategorien einstellen: rollenspezifisch, für

alle Benutzer zugelassen bzw. für alle gesperrt. Soll rollenspezifisch über den Zugriff entschieden werden, muss jede Rolle, die Zugriff erhalten soll, mit einer Checkbox markiert werden.

• Die vom Entwickler erzeugten logischen Rollen, die im Code benutzt werden, lassen

sich hier auf die im System vorhandenen Rollen abbilden. „Coded name“ wäre hierbei die Rollenreferenz innerhalb des Codes und über „Role name“ kann die Systemrolle über ein Puldownmenü zugeordnet werden.

Client-Tier Sicherheit

Webclients Die Spezifikation erlaubt prinzipiell drei Arten von Webclient-Authentisierung, die über den Server einstellbar sein müssen:

• http bzw. http über SSL (https) – Es werden http-Formulare mit einfacher Login/Passwort-Abfrage benutzt.

• formular – Agiert auch über http/https. Diese Einstellung erlaubt jedoch eigens definierte und umfangreichere Abfragen. Es können Mechanismen wie Cookies bzw. Session-Ids benutzt werden.

• client-certificate – Erlaubt die Authentifizierung von Webclients über Zertifikate. Für

diese Option muss zur gegenseitigen Authentisierung (mutual authentication) natürlich auch auf Client-Seite ein X.509-Certificate installiert sein.

Der im Mid-Tier genauer beschriebene rollenbasierte Zugriffsschutz wird auch bei Webapplikationen vom Container übernommen. Es sind auch bei Webanwendungen programmatische statt vom Container übernommene Sicherheitsabfragen möglich: Über das HttpServletRequest Interface kann mit der Methode isUserInRole festgestellt werden, ob der Benutzer in einer Bestimmten Rolle ist. Um die Identität (in Form eines java.security.Principal) zu erhalten, kann die Methode getUserPrincipal verwendet werden.

Applicationclients Seit der Version 2.0 ist es für J2EE-kompatible Server verpflichtend, eine Unterstützung für den Java Authentication and Authorisation Service (JAAS) zu bieten. Damit ist es möglich, Application-Clients zu authentifizieren. JAAS implementiert eine Version des Pluggable Authentication Module (PAM) Frameworks und erlaubt den Einsatz von eigens entwickelten Loginmodulen. Diese Loginmodule werden auf Seiten des Clients eingesetzt. So ist es verschiedenen Applicationclients möglich, auch verschiedene Loginvarianten zu unterstützen. Beispielsweise wäre neben einem simplen Modul für Name/Passwort-Dialoge auch ein Modul denkbar, das mithilfe von externer Hardware und Smartcards arbeitet, oder Zertifikate weiterreicht. Die Loginmodule selbst steuern den Loginvorgang und sammeln Authentisierungsdaten über sogenannte Callbackhandler. Darüber werden auch Satusinformationen vom Server an den Client zurückgereicht. Die jeweilige Applikation auf Client-Seite muss dazu dem Server u.A. mindestens eine Klasse anbieten, die das Interface javax.security.auth.callback.CallbackHandler implementiert. Durch die Benutzung über solche Interfaces bleibt die Implementierung von Loginmodulen austauschbar. Ist der Einsatz von JAAS nicht erwünscht, kann der Container den Vorgang der Authentisierung über voreingestellte Mechanismen komplett selbst übernehmen. Die Vorgehensweise dabei ist allerdings abhhängig von der Implementierung. Dazu ist die Clientsoftware entsprechend einzurichten. Beim J2EE-SDK ist der Server mithilfe des „deploymenttools“ auf die Zusammenarbeit mit Applikationen konfigurierbar, die JAAS-Module zur Authentisierung verwenden wollen. Hierzu muss die Klasse der Applikation angegeben werden, die das oben genannte Callbackhandler-Interface implementiert. Wird keine Klasse der Client-Anwendung ausgewählt, ist der default-Wert „Use container-managed authentication“:

Message-Driven Beans Die Message-Driven Beans (MDB) sind in Bezug auf Sicherheit gesondert zu handhaben. Sie werden nicht wie die anderen EJB über den EJBContext und JNDI referenziert, sondern reagieren auf Nachrichten des Java Messaging Service JMS. Da die Messages an sich keinen Sicherheitskontext mitübertragen, muss der Assembler den Nachrichtenfluss kontrollieren. Hierzu bindet er die MDB an zugehörige Nachrichtenwarteschlangen. (Message-Queues), die von JMS-Applikationen verteilt werden (JMS-Provider). Ausschließlich über diese Queues dürfen dann Nachrichten ausgetauscht werden. Der Container kümmert sich weiterhin, genauso wie bei den anderen Beanarten, um die Umsetzung des rollenbasierten Zugriffschutzes. Dazu müssen zusätzlich die für die Bearbeitung von Nachrichten speziell zu implementierenden Methoden nur für bestimmte Rollen freigegeben werden (etwa die onMessage-Methode). Das müssen natürlich die Rollen sein, von denen man empfangen möchte. Die JMS-Provider können in den Server per „resource adapter“ integriert, aber auch separat betrieben werden. Hierfür muss ein J2EE-konformer Server ebenfalls Tools zur Einbindung und Konfigurierung bereitstellen. Deployment-descriptor eines Nachrichten produzierenden MDB (Producer): … <message-destination-ref> <message-destination-ref-name>jms/StockInfo</message-destination-ref-name> <message-destination-type>javax.jms.Queue</message-destination-type> <message-destination-link>EmailMDB</message-destination-link> <message-destination-link>QueryMDB</message-destination-link> </message-destination-ref> …

Das <message-destination-link>-Element bindet hierbei den Producer an die Beans EmailMDB bzw. QueryMDB. Nur an sie können Nachrichten versendet werden. Über <message-destination-ref-name> wird der Name des Producers in JNDI festgelegt. Consumer-Programmcode: // Look up the JMS StockQueue in the environment. Object result = initCtx.lookup("java:comp/env/jms/StockInfo"); // Convert the result to the proper type. javax.jms.Queue queue = (javax.jms.Queue)result; Es wird über den oben deklarierten JNDI-Namen der Producer referenziert. Deployment-descriptor des Consumers: <ejb-jar> <enterprise-beans> <message-driven> <ejb-name>EmailMDB</ejb-name> <ejb-class>com.customware.ejb.EmailMDB</ejb-class> <transaction-type>Container</transaction-type> <message-destination> <message-destination-name>EmailMDB</message-destination-name> <message-destination-type>javax.jms.Queue</message-destination-type> </message-destination> <message-destination-ref> <message-destination-link>jms/StockInfo</message-destination-link> <message-destination-usage>Consumes</message-destination-usage> </message-destination-ref> <security-identity> <run-as-specified-identity> <role-name>system</role-name> </run-as-specified-identity> </security-identity> </message-driven> </enterprise-beans> </ejb-jar> In diesem Abschnitt ist zu sehen, wie das Bean EmailMDB an einen Producer mit JNDI-Namen „jms/StockInfo“ gebunden wird. Das geschieht mittels des <message-destination-link>-Elements. Dieses Element ist nicht eindeutig (es wird auch bei den Producern verwendet). Es ist oft so, das gleiche Elementnamen in unterschiedlichen Abschnitten verschiedene Bedeutungen haben. Dieses Element muss also im Kontext betrachtet werden. Zusätzlich ist das Bean mit <message-destination-usage> als reiner Konsument eingetragen. Ebenfalls zu sehen ist, das <run-as-specified-identity> das Bean immer die Rolle „system“ propagieren lässt. Seit EJB 2.1 ist es Message-Driven Beans auch möglich, neben dem JMS auch andere Arten von Message Oriented Middleware (MOM) zu unterstützen. Message-Driven Beans akzeptieren somit zusätzlich Nachrichten im SOAP-Format bzw. dem Java API for XML Messaging (JAXM). Damit fällt es dem Programmierer zu, diese SOAP-XML-Nachrichten in seine Bestandteile zu zerlegen und zu interpretieren. Das Sicherheitskonzept der MDB ist aber unabhängig davon, ob JMS oder JAXM benutzt wird. Das bedeutet, daß bei beiden Varianten sowieso kein Sicherheitskontext übertragen wird, sondern allein die Bindungen der Konsumenten an die Nachrichtenwarteschlangen eingestellt werden kann. Diese Warteschlangen müssen somit in jedem Fall vertrauenswürdig sein. Es muss insbesondere auch bei der Unterstützung von JMS-fähigen Client-Anwendungen (JMS-Clients) eine gegenseitige Authentisierung von Client und Queue sichergestellt werden (so etwa möglich beim Sun ONE Application Server). Im folgenden Screenshot des deployment tools ist exemplarisch zu sehen, wie die Bindung von MDBs an festgelegte JMS-Warteschlangen

(hier als Ziel der Nachrichten) aussehen kann. In diesem Fall handelt es sich um einen JMS-Client.

Der Beispielserver bringt zur Einbindung u.A. der JMS-Dienste ein „j2eeadmin“-Kommandozeilentool mit. Für die Einbindung eines JMS wäre der fett hervorgehobene Abschnitt zu beachten. Wie man sieht, gibt es bei dieser Implementierung an dieser Stelle keinerlei Einstellungen für einen Sicherheitskontext. Erwünschenswert wären z.B direkte Optionen für gegenseitige Authentisierung. Usage: -addJdbcDriver <class name> -addJdbcDatasource <jndi name> <url> -addJdbcXADatasource <jndi name> <class name> [<xa user name> <xa password>] [-props (<name>=<value>)+] -addJmsDestination <jndi name> (queue|topic) -addJmsFactory <jndi name> (queue|topic) [-props (<name>=<value>)+] -addAdminObject <jndi name> [<app name>:]<rar filename> -type <adminobject type> [-props (<name>=<value>)+] -addConnectorFactory <jndi name> <moduleID of resourceadapter> [<xa user name> <xa password>] [-type <connection factory type>] [-props (<name>=<value>)+] -list<resource type> -remove<resource type> <name> -removeAll<resource type> -ejbtimers

JNDI-Security Möchte eine Client-Anwendung z.B. eine Methode eines (Session- oder Entity-) EJB aufrufen, erhält es nach Anfrage an das Java Naming and Directory Interface (JNDI) einen Verweis auf ein EJB-HomeInterface. Über dieses Interface generiert er einen Verweis auf das Remote-Interface des EJB, über das dann die (Geschäfts-) Methoden des EJB aufgerufen werden können. Für den lokalen Zugriff müssen Beans auch einen Satz Local Interfaces bereitstellen. Darüber können dann andere Beans innerhalb des Containers oder

Webanwendungen auf dem selben Server zugreifen. Der JNDI-Dienst kann, ähnlich wie JMS, in den J2EE-Server integriert sein, aber auch separat als eigentständiger Server betrieben und dann eingebunden werden. Es müsste im J2EE-Server somit ein Mechanismus implementiert sein, um Mutual Authentication mit dem JNDI-Dienst zu ermöglichen, was aber bislang selten der Fall ist. Gelänge es, einem Client oder dem Container einen falschen JNDI-Namespace zuzuspielen, könnte man ihnen darüber auch falsche Home-Interfaces und folglich falsche und böswillige Objektreferenzen zukommen lassen. Authentisierungsdaten könnten so z.B durch spoofing eines Loginvorgangs abgefragt werden. Andererseits muss auch der JNDI-Dienst gesichert werden, da ansonsten auch unberechtigte Server Einträge in den Dienst vornehmen können. Die J2EE-Spezifikation rät zur Sicherung der Name-services und zur Verwendung von „CORBA specified naming services“ (Cos-Naming) über eine sichere Verbindung. Die Umsetzung allerdings ist den Serverentwicklern überlassen, da auch die verschiedenen CORBA-Implementierungen nicht immer eine Sicherung ihrer Namensdienste unterstützen. Im folgenden sei eine Client-Initialisieung des JNDI-Kontextes exemplarisch dargestellt: … // Set up the environment properties Hashtable h = new Hashtable(); h.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); h.put(Context.PROVIDER_URL, "t3://localhost:7001"); h.put(Context.SECURITY_PRINCIPAL, "username"); h.put(Context.SECURITY_CREDENTIALS, "password"); // Get an InitialContext return new InitialContext(h); …

Container-Container Kommunikation Die Kommunikation zwischen Containern, die auf verteilten Servern laufen, ist größtenteils durch den Java Authorization Contract for Containers (JACC) geregelt. EJB-Spezifikation 2.0 sieht bei der Interaktion zwischen Containern das CORBA Transport-Protokoll IIOP (Internet Inter-ORB Protocol über TCP/IP) vor. Um genau zu sein, wird eine Ergänzung zu diesem Protokoll vorgeschrieben, nämlich CSIv2 (Common Secure Interoperability version 2) . Es ergänzt das IIOP-Protokoll um die Möglichkeit, Authentifizierungs und Authorisierungsdaten zu übermitteln. Der Sicherheitskontext von Applikationen wird dabei in dem „service context“ – Feld der IIOP Header übertragen. Dieses Headersegment ist von den Applikationdaten und anderen Protokollheadern abgekapselt. CSIv2 verwendet SSL (3.0) bzw. TLS (1.0) als Übertragungsprotokoll über TCP/IP. Das von EJB verwendete RMI (Remote Method Invocation) läuft schließlich über CSIv2. Vorherige Versionen schrieben zur Kommunikation nur das pure RMI-Protokoll vor, das von Natur aus für Sicherheitsinformationen keinen Platz läßt und auch nur mit Java-Komponenten kommunizieren kann. Dies war ein weiterer Grund für die Einführung von IIOP/CSIv2, nämlich die Interoperabilität von Java und CORBA-Applikationen (besonders in Bezug auf Sicherheit). Seit Version 2.0 muss SSL (zwangsläufig durch CSIv2) für die Kommunikation zwischen den Servern einer verteilten Applikation unterstützt werden, was auch eine Manipulation des übertragenen Sicherheitkontext verhindert. Die Handhabung und Einstellungen des SSL-Protokolls (welche Algorithmen verwendet werden etc.) ist abhängig von der jeweiligen Implementierung, denn es ist nicht zwingend vorgeschrieben, daß Einstellungen in Bezug

auf die Container-Container Kommunikation durch den Endnutzer konfigurierbar sein müssen. Es sind für SSL allerdings einige Verschlüsselungsalgorithmen zwingend vorgeschrieben (darunter z.B SSL_RSA_WITH_RC4_128_MD5, also eine 128-Bit RSA/RC4-Verschlüsselung mit MD5-Hashing).

Realms Bei der J2EE-Spezifikation werden realms als eine Gruppe von Benutzern definiert, die alle mit dem selben Mechanismus authentisiert werden (ein realm wäre etwa „certificate“ und „ldap“, wie beim Sun ONE Application Server). Realms werden auch manchmal als „security policy domains” bezeichnet. Innerhalb dieser Realms gelten dann die Zuordnungen von Rollen an Benutzer. Bei der Verwendung verschiedener Loginverfahren über JAAS ist es möglich, das System in Realms für jedes Verfahren einzuteilen. Das ist aber abhängig von der jeweiligen Implementierung, ebenso wie z.B. Einteilungen in LDAP-Realms und Betriebssystem-Realms. Beim Beispielserver des J2EE-SDK werden realms mithilfe des „realm tools“ verwaltet. Es können dort den festgelegten Realms einzelne Benutzer oder Benutzergruppen hinzugefügt werden. Folgend ist ein Auszug der Optionen aus der Kommandozeile dargestellt, um die Einstellungsmöglichkeiten zu veranschaulichen. RealmTool Options -show -list realm-name -add username password group[,group] -addGroup group -import certificate-file -listGroups -userGroups username -remove realm-name username -removeGroup group

Legacy Tier

Es gibt zwei Möglichkeiten, den Container, bzw. die Beans die in ihm laufen, gegenüber Legacy-Systemen wie etwa Datenbanken oder Gateways zu authentisieren. Die Systeme an sich erfordern meist die Eingabe eines Namen und Passworts oder benutzen andere Loginvarianten. Die beiden Möglichkeiten sind „Container-managed“ und „Bean-managed“. Bei der Option Container-managed übernimmt der Container die Loginprozedur. Dazu ist dann z.B die vorherige Eingabe der Namen und Passwörter im deploytool erforderlich. Innerhalb des Codes ist also nur die Anfrage einer Verbindung zu der Ressource notwendig, der Container übernimmt dann das Loginverfahren. // Invoke factory to obtain a connection. The security // information is not passed in the getConnection method javax.resource.cci.Connection cx = cxf.getConnection(); Bei Bean-Managed kann der Loginvorgang direkt im Bean-Code übernommen werden: // Invoke factory to obtain a connection com.myeis.ConnectionSpecImpl properties = //.. // get a new ConnectionSpec properties.setUserName("...");

properties.setPassword("..."); javax.resource.cci.Connection cx = cxf.getConnection(properties);

Role Based Access Control (RBAC) Zunächst ein kurzer Überblick über RBAC: RBAC0 :Benutzer werden Rollen zugeordnet, wie z.B Kunde, Angestellter, Chef. Diesen Rollen werden Rechte (permissions) zugeordnet, die man als Capabilities auf Objekte/Ressourcen auffassen kann. Sitzungen bezeichnen die Zuordnung von (u.A. mehreren) Rechten auf Benutzer während der Aktivität im System. RBAC1 erweitert RBAC0 um Rollenhierarchien. Rollen können Rechte voneinander erben. RBAC2 erweitert RBAC0 um Einschränkungen. z.B. „Kassierer darf nicht Kassenprüfer sein“ RBAC3 kombiniert RBAC1 und RBAC2. Einschränkungen wie „keine Mehrfachvererbung“ möglich.

• RBAC0 = Benutzer + Rechte + Sitzungen • RBAC1 = RBAC0 + Rollenhierarchien • RBAC2 = RBAC0 + Einschränkungen • RBAC3 = RBAC1 + RBAC2

Es ist eine direkte Umsetzung von RBAC0 in J2EE-Systemen möglich:

• Benutzer entsprechen hier den Benutzern des Systems (den Clients) • Rollen in RBAC entsprechen den Rollen innerhalb der J2EE-Applikation. • Rechte (Permissions) sind definiert durch die Zugriffsrechte auf die einzelnen

Methoden der EJBeans (mithilfe von <method-permission>-Elementen im deployment-descriptor).

• Als Sitzung kann die Zuordnung von Principals zu Subjects aufgefasst werden. Diese Security Identities werden verwendet, um dem Subject bestimmte Rollen anzuheften.

Um weitere RBAC-Level umsetzen zu können, muss der Server erweiternde Funktionen bereitstellen, die abhängig von der Implementierung sind. Bei einer erwünschten Rollenhierarchie müsste der Container z.B. eine Funktion roles() bereitstellen, die nicht nur die aktive Rolle des Aufrufenden, sondern auch alle ihr untergeordneten Rollen zurückgibt.

Fazit und Ausblick Die J2EE-Spezifikation bietet auf dem jetzigen Stand neben Stärken wie dem rollenbasierten Zugriffsschutz und der Unterstützung von sicheren Kommunikationsformen an den meisten Schnittstellen jedoch noch einige Schwächen. Bislang scheint es nicht geklärt zu sein, wie Namens- und Verzeichnisdienste wie JNDI, sowie Nachrichtendienste wie JMS einheitlich gegenüber dem J2EE-Server und Klienten authentisiert werden können. An manchen Stellen scheint die Spezifikation sehr weite Spielräume für die Implementierung zu lassen, was Server mit sehr unterschiedlichen Sicherheitsstufen hervorbringen wird. Version 1.4 schreibt keinerlei Mechanismen für Auditing vor, also dem Protokollieren von sicherheitsrelevanten Systemvorgängen. Da es mithilfe von Auditing-Systemen u.A. möglich ist, Angriffszenarien und Sicherheitslöcher nachzuvollziehen, stellt Auditing ein wichtiges

Werkzeug zur Systemsicherung dar. Es sollte in künftigen Versionen nicht fehlen – es wird bereits Besserung versprochen. Als weitere „Future Direction“ soll es in künftigen Versionen noch mehr Kontrolle über die Sicherheitsfeatures geben. Dazu sollen die bisherigen APIs erweitert werden: „However, some applications need more control over security than can be provided by this approach. A future version of this specification may expand the set of APIs available to control authentication and authorization, and to allow the integration of new security technologies.“(J2EE.11.5) In Zukunft sollen der Spezifikation weiterhin noch Mechanismen zur User-Registrierung hinzugefügt werden, was bis jetzt überhaupt nicht behandelt wurde. Positiv ist zu beurteilen, das Tools zur Administration in vielen Bereichen durch die Spezifikation vorgeschrieben sind. Das kann „einfache“ Einstellungen der Sicherheitspolitik ermöglichen. Eine Politik in XML per Hand umzusetzen dürfte schnell zu unübersichtlichen Systemen führen. Es ist wichtig, Sicherheit für alle „3 players“ transparent, aber nicht zu oberflächlich zu gestalten. Ein guter Weg scheint hier der Gedanke zu sein, Sicherheit deklarativ, anstatt programmatisch umzusetzen.

Quellen Java 2 Platform Enterprise Edition Specification, v1.4 (Public Draft) Java Authorisation Contract for Containers (JACC) (Proposed Final Draft, Version 1.0) http://java.sun.com http://java.sun.com/j2ee/1.4/docs/ http://www.iona.com http://docs.sun.com/source/816-7149-10/ (Sun ONE Application Server 7 Developer's Guide)

Enterprise Security with EJB and Corba (Bret Hartman, Donald J. Flinn, Konstantin Beznosov) Java Magazin 12/02 (EJB), 9/02 (JAAS)