J2EE – Deklaratives Sicherheitsmodell der EJB 2 by ygq15756

VIEWS: 0 PAGES: 35

									Seminar Security Engeneering
                                                      Martin Kammerlander SS 2004




     J2EE – Deklaratives
 Sicherheitsmodell der EJB
 2.0 am Beispiel der JBOSS
    SX Security Extension




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 1
Seminar Security Engeneering
                                                           Martin Kammerlander SS 2004




              Inhaltsverzeichnis
   1. Enterprise Java Beans
      1.1 Was versteht man unter EJB’s
      1.2 Der EJB Container
          1.2.1 Laufzeitumgebungen
          1.2.2 Dienste
      1.3 Unterschiedliche Typen der EJB’s
          1.3.1 Session Beans
          1.3.2 Entity Beans
          1.3.3 Message Driven Beans


   2. EJB Client Server Modelle
      2.1 EJB Client
      2.2 EJB Server


   3. Sicherheitsmodelle der EJB
      3.1 Programmatische Sicherheit
      3.2 Deklarative Sicherheit


   4. Deklaratives Sicherheitsmodell der EJB
      4.1 Der JBoss Application Server
      4.2 Deklarative Sicherheit anhand des JBoss
          4.2.1   Übersicht über die deklarative Sicherheit in J2EE
          4.2.2   JBoss Security
          4.2.3   Java Authentification and Authorization Service (JAAS)
          4.2.4   Wichtige Elemente der JAAS Implementierung
             4.2.4.1    Security References
             4.2.4.2    Security Identity
             4.2.4.3    Security Roles
             4.2.4.4    EJB Method Permissions
             4.2.4.5    Web Content Security Constraints
          4.2.5 Was genau ist JAAS?
             4.2.5.1    Die JAAS Kern-(Core) Klassen
             4.2.5.2    Authentifizierung eines Subjects

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 2
Seminar Security Engeneering
                                                       Martin Kammerlander SS 2004




   5. Das JBoss Security Modell
      5.1 Security Intefaces
      5.2 Beispiel EchoSecurityProxy


   6. JBoss SX Security Extension
      6.1 Wie benützt der JaasSecurityManager JAAS?




Erklärung:

Die Ausarbeitung konzentriert sich im Wesentlichen auf die nun folgenden Punkte,
wobei nicht einzig und allein über das deklarative Sicherheitsmodell gesprochen
werden kann und soll, sondern, als Einführung gedacht, auch allgemein die
Enterprise Java Beans behandelt werden.




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 3
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004




                   1. Enterprise Java Beans

   1.1 Was versteht man unter EJB’s?

Ins Deutsche übersetzt bedeutet der Ausdruck Enterprise Java Beans nichts anderes
als: Unternehmens Java Bohnen.
Diesen Namen verdanken sie, wie schon die Programmiersprache Java selbst, der
inzwischen schon berühmten indonesischen Insel Java einerseits und andererseits
der auf der Insel wachsenden beliebten Kaffeesorte den „Java Beans“.

EJB’s sind Programmkomponenten und werden zur Modellierung und Steuerung von
Geschäftsprozessen eingesetzt.
Die EJB’s sind das eigentliche Kernstück der „Java 2 Platform, Enterprise Edition"
(J2EE), deren Architektur für Softwarekomponenten von der Firma Sun
Microsystems spezifiziert wurden.
J2EE stellt ein reines Java Umfeld für die Entwicklung und die Ausführung von Web-
basierten Anwendungen zur Verfügung.
Die Verwendung einer so genannten Containerschicht ermöglicht den Zugriff auf
gemeinsam genutzte Funktionen wie z.B. Datenübertragung und Datensicherung in
einer Datenbank.
EJB’s können nur in der Programmiersprache Java entwickelt werden, bieten aber
den großen Vorteil von Java und lassen sich also auf beliebigen Rechnerplattformen
einsetzen.
Ausserdem stellen sie allen Anwendungen eine einheitliche Oberfläche zur
Verfügung, unabhängig davon welcher Servertyp eingesetzt wird.
Dem Applikationsentwickler erlauben die EJB’s sich auf die Entwicklung der
Applikations- und Businesslogik zu konzentrieren, d.h. die Entwickler erstellen die
Datenbank und kümmern sich um die Datenbankanbindungen, verarbeiten diese
Daten und bereiten sie für die Darstellung in der Präsentationschicht vor.




   1.2 Der EJB Container

Ein EJB-Container stellt eine Laufzeitumgebung für die EJB’s dar. Er stellt also den
Komponenten zur Laufzeit bestimmte Dienste wie Transaktions-, Deployment-,
Namensdienste zur Verfügung.

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 4
Seminar Security Engeneering
                                                           Martin Kammerlander SS 2004
Der Container übernimmt ausserdem das Management der Sicherheit und legt den
Lebenszyklus der EJB’s fest.


   1.2.1 Laufzeit umgebungen

Kontrolle des Lebenszyklus einer Enterprise Bean:

      Bei Anfragen eines Clients erzeugt, zerstört oder recycelt der Container die
       Bean Instanzen.
      Existiert eine Instanz noch nicht, wenn der Client eine Anfrage startet, wird der
       Container diese erzeugen.
      Existiert die Instanz bereits, so wird diese einfach an den Client Weitergeleitet.
      Wird eine Instanz nicht mehr benötigt, so wird diese gelöscht.


Instanzen-Pooling und Aktivierung bzw. Passivierung:

      Anwendungssysteme müssen mit grossen Belastungen zurechtkommen, d.h.
       sie müssen sehr vielen gleichzeitigen Clientanfragen standhalten.
      Je grösser die Anzahl der Anfragen der Clients werden, umso mehr Instanzen
       müssen erzeugt werden.
      Damit die Anzahl der Bean-Instanzen nicht unkontrolliert wächst, hält der
       Container eine bestimmte Anzahl von Instanzen in einem so genannten Pool
       bereit.
      Solange die Instanzen also nicht gebraucht werden sind sie also im Zustand
       Pooled, und nicht aktiv.
      Wird eine Instanz benötigt, so wird die passende Bean aus dem Pool
       entnommen und wieder reaktiviert (Ready).



Verteilung:

      Der EJB-Container sorgt dafür, dass die Clients die EJB’s benutzen können.
      Für den Client ist es unwichtig wo sich die EJB’s auf dem Server befinden.
      Der EJB-Container sorgt dafür, dass die EJB’s innerhalb des Containers, von
       außen angesprochen werden können.



Transaktion:

      Wenn mehrere Clients gleichzeitig auf gemeinsame Daten am Server
       zugreifen, kommt es oft zu Fehlern.
      Auszuführende Aktionen werden vom Entwickler in Transaktionen unterteilt.
      Der EJB-Container muss dafür sorgen, dass die einzelnen Aktionen der
       Transaktionen erfolgreich durchgeführt werden.

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 5
Seminar Security Engeneering
                                                              Martin Kammerlander SS 2004
          Tritt ein Fehler auf, müssen alle bisherigen Aktionen wieder rückgängig
           gemacht werden.



Sicherheit:

           Jeder EJB-Container stellt eine Infrastruktur für das Sicherheitsmanagement
            als Bestandteil der Laufzeitumgebung zur Verfügung.
           Derjenige der die EJB’s installiert muss auch die Sicherheitspolitik festlegen.
           Aufgabe des Containers ist es die Sicherheitspolitik umzusetzen.
           Im Code Der EJB’s sollte so wenig wie möglich, bis keine
            Sicherheitsmechanismen eingebaut werden. So können sie in vielen
            verschiedenen Systemen eingesetzt werden (programmatisch).
           Sinnvoller ist also die Verlagerung der Sicherheitsmechanismen in die
            Laufzeitumgebung der Komponenten (deklarativ).


   1.2.2 Dienst e


Namensdienst:

          Der Client braucht einen Namensdienst, damit er ein Bean im Server bzw.
           Container finden kann.
          Namensdienste bieten ausserdem die Möglichkeit, Referenzen auf bestimmte
           Objekte und unter einem bestimmten Namen an einen vorbestimmten Platz zu
           legen (binding).
          Außerdem findet der Namensdienst die gebundenen Objekte anhand des
           Namens wieder (loockup).


Verzeichnisdienst:

          Unterstützt zusätzlich auch noch das Verwalten und die Administrationen von
           Ressourcen wie z.B. Drucker, Dateien usw.


Persistenz:

   Den EJB’s wird über dem Container die Möglichkeit geboten, über die
    Namens- bzw. die Verzeichnisdienste auf die Datenbank zuzugreifen.
   Sie können also selber „entscheiden“ ob ihr Zustand persistent sein soll, oder
    nicht persistent.
   Automatische Persistenz: Ablagerung der Daten durch die EJB’s über den
    Container in einer Datenbank (oder z.B. Übergabe an ein Entity Bean).
   Für ein EJB ist es unwichtig wo und wie die Daten in der Datenbank (oder an
    einem anderen Ort) abgespeichert werden. Nur der Container muss dafür
    sorgen, dass die Daten gespeichert werden und somit konsistent bleiben.
Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                            Seite 6
Seminar Security Engeneering
                                                       Martin Kammerlander SS 2004




   1.3 Unterschiedliche Typen der EJB’s
1.3.1 Session Beans

Session Beans werden dazu verwendet um Anwendungslogik auf dem Server
auszuführen.
Für jeden Client wird durch den EJB-Server und dem Container ein eigenes Bean
erzeugt, auf das nur dieser eine Client die Zugriffsrechte besitzt.
Session Beans sind nicht persistent.
Wird also die Verbindung zwischen durch den Server oder dem Client unterbrochen,
so wird auch die Instanz des Session Beans durch den Container zerstört. Das hat
zur Folge, dass bei einem Absturz eines Systems, sei es Client- oder Serverseitig,
alle Informationen die das Bean beinhaltet, verloren gehen.
Ausgenommen sind dabei natürlich die Informationen die an die Datenbank oder an
ein persistentes Bean, wie z.B. ein Entity Bean, weitergeleitet wurden.

Session Beans werden noch weiter unterschieden und zwar in stateless und statefull.


Stateless Session Beans:

Zustandslose Beans können sich eine vorausgegangene Anfrage merken und in
Einbezug dieser Anfrage reagieren. Stateless Beans werden also bei einfachen
Methodenaufrufen verwendet.

Ein Beispiel:
Bei einer Onlineüberweisung wird der TAN Code und der zu überweisende Betrag
übermittelt. Das Bean überprüft den Kontostand des Users und gibt dem User eine
positive oder negative Bestätigung zurück.


Statefull Session Beans:

Zustandsbehaftete Session Beans hingegen sind kompliziertere EJB’s. Bei ihnen
wird der Zustand der Konversation mit dem Client gespeichert.

Ein Beispiel:
Bei einem Onlineshop werden Waren von einem Benutzer in den Warenkorb
gegeben. Das statefull Session Bean muss sich nun natürlich merken welche Waren
der User in den Warenkorb gelegt hat. Das heisst, es speichert den gesamten
Verlauf des Onlinekaufes.
Wird jedoch die Verbindung zwischen Client und Server gestört, gehen auch hier alle
Daten (Produkte im Warenkorb) verloren. Der Kunde muss also beim erneuten
einloggen in die Seite alle Waren neu in den Korb legen, was bei diesem Beispiel
auch ordentlich Sinn macht.
Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 7
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004




1.3.2 Entit y Beans

Entity Beans sind geeignet für die Abarbeitung von permanenten Daten, da sie
Persistenz gewährleisten.
Bei den Entity Beans besteht nicht für jeden einzelnen Client eine Instanz, sondern
für alle Clients eine gemeinsame, wobei auch gleichzeitiger Datenbankzugriff möglich
ist.
Entity Beans überleben sogar Serverabstürze, da sie eng mit der Datenbank
verbunden sind.

Auch die Entity Beans werden in zwei verschiedene Arten aufgeteilt:


Bean Managed Entity Beans:

Bei den Bean Managed Entity Beans muss sich der Komponentenentwickler selbst
um die Persistenz kümmern.
So muss er z.B. die Verbindung zu einer Datenbank selbst aufbauen und alle
Vorgänge, die Datenbank betreffend regeln. Der Komponentenentwickler kann z.B.
über JDBC eine Verbindung des Entity Beans mit der Datenbank herstellen.
Leider ist die Komponente dann an die jeweilige Datenbank gebunden und nicht
mehr unabhängig von der Datenbank einsetzbar, was wiederum dem eigentlichen
Komponentenmodell widerspricht.


Container Managed Entity Beans:

Hier übernimmt der Container die Aufgaben rund um die Datenbank (automatische
Persistenz). Der Entwickler selbst beschreibt ausschließlich welche Daten
gespeichert werden müssen.
Der grosse Vorteil liegt darin, dass die Beans unabhängig von der Datenbank
eingesetzt werden können.


1.3.3 Message Driven Beans

Die Message Driven Beans sind eine neuere Art von Beans und sind in der EJB 2.0
spezifiziert.
Ein Vorteil dieser Beans ist, dass Methodenaufrufe nicht mehr ausschliesslich
synchron durchgeführt werden müssen, sondern dass nun auch asynchrone
Methodenaufrufe möglich sind.
Clients können nun Nachrichten schicken, diese gelangen in eine Warteschlange
und die Clients können sofort weitermachen, ohne auf die Antwort des Servers zu
warten.


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 8
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004
Ein Beispiel:

Wieder anhand eines Onlineshops.
Ein Client kauft eine bestimmte Ware, wartet aber nicht auf die Bestätigung auf der
entsprechenden Seite sondern geht sofort offline.
Bei der Bestellung kann es vorkommen, dass der Shop erst die Verfügbarkeit des
Artikels prüfen muss, die Bestellung also in eine „Warteschlange“ kommt.
Ist die Verfügbarkeit geprüft, erhält der Client die Bestätigung oder Die Absage z.B.
über SMS oder E-Mail.




                2. EJB Client- Servermodelle

   2.1 EJB Client

Das Client Tier (Die Client Schicht) unterstützt sehr viele verschiedene Clienttypen.
Die Clients können sowohl vor als auch hinter einer Firewall auf den Server
zugreifen.
EJB Clients sind so genannte Application Clients und kommunizieren mit dem EJB
Tier. Bei diesen Clients handelt es sich um Programme mit graphischer Oberfläche,
welche auf einem handelsüblichen Computer lauffähig sind. Die PC’s verwalten die
graphische Oberfläche selber. Für die Kommunikation mit dem EJB Server wird
meist RMI (Remote Method Invocation) verwendet. RMI erlaubt es Methoden auf
Objekte anzuwenden welche in einer anderen Java Virtual Machine ablaufen.
Vorteile eines EJB Clients sind z.B. ein flexibles User Interface, Aufteilung und
Behandlung von komplexen Daten und bereits integrierte Sicherheitsmechanismen.
Auch können Clients in anderen Programmiersprachen (nicht Java) implementiert
werden.




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                           Seite 9
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004




Abbil dung 1: Drei Schichten Modell



    2.2 EJB Server

Ein EJB Server hat viele verschiedene Aufgaben. Er muss verschiedenste Dienste,
wie die Verwaltung des Gesamtzustandes, den Zugriff auf gemeinsame Daten,
Transaktionen, Zugriff von sehr vielen Clients und Zugriffe auf verschiedenste Daten,
regeln.
Die einzelnen Komponenten (unter anderem die EJB’s) sind Unterprogramme des
Servers.
Der Server verwaltet den (die) EJB Container und stellt die Laufzeitumgebung des
Containers dar. Der Container wiederum stellt die La ufzeitumgebung Der EJB’s dar.
EJB Server




 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 10
Seminar Security Engeneering
                                                       Martin Kammerlander SS 2004




Abbil dung 2: Modell der Server -Container Schicht




    3. Sicherheitsmodelle der EJB


    3.1 Programmatische Sicherheit

Bei der programmatischen Sicherheit erfolgt die Steuerung des Zugrif fs im
Programmcode des Beans selber.
Wenn bereits im Programmcode z.B. Rollen (Security Roles) definiert werden,
brauchen sie im Deployment Descriptor nur noch deklariert werden.
Programmatische Sicherheit, d.h. Im Code selber die Sicherheit zu implementieren,
sollte aber nach Möglichkeit vermieden werden, da sie dem Komponentenmodell
widersprechen (wiederverwendbare Komponenten).
Natürlich ist es nicht immer möglich auf die programmatische Sicherheit zu
verzichten.

Ein Beispiel:
Sollen z.B. Aktionen bzw. Methodenaufrufe nur zu einer bestimmten Tageszeit
ausführbar sein, dann muss dies im Bean selber programmiert sein.
Grund dafür ist, dass die nötigen Werte zur Überprüfung dieser Bedingung erst zur
Laufzeit festgelegt werden.


Der Programmierer der EJB’s hat eigentlich die Aufgabe sich möglichst um die
Umsetzung von Geschäftsabläufen und die Wiederverwertbarkeit seiner
Komponenten zu kümmern. Außerdem weiss er meist nicht welche Rollen z.B. später
in der Anwendung gebraucht werden.
 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 11
Seminar Security Engeneering
                                                            Martin Kammerlander SS 2004
Trotzdem kann der Entwickler so genannte logische Rollen implementieren.
Rollen wie z.B. „Admin“ oder „User“ werden ja fast überall benötigt.
Später werden diese logischen Rollen mithilfe des deployment descriptors den
tatsächlichen Rollen im System zugewiesen.

Beispiel: Logische 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>
…

Beispiel: Zuordnung von Rollenreferenzen auf System-Rollen (deklarativ):



...
<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>

Hier wird sozusagen die im Programmcode festgelegte Rolle „admin“ mit der Rolle
„staff“ verlinkt. Dies ist die Aufgabe des Deployers.




   3.2 Deklarative Sicherheit

Die Deklarative Sicherheit kommt ohne einen Eingriff in den Quellcode der Beans
aus.


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 12
Seminar Security Engeneering
                                                         Martin Kammerlander SS 2004
Ausschließlich stützt sie sich auf den Deployment Descriptor. Mit ihm kann z.B.
festgelegt werden, welche Rollen im System Zugriff auf gewisse Ressourcen haben.
Zugriffsrechte können bei Deklarativer Sicherheit einzig und allein über Rollen
vergeben werden.
Die Idee hinter dem Deklarativen Sicherheitsmodell ist jene, dass die Sicherheit nicht
Aufgabe des Programmierers sein soll. Dieser weiss auch vorher noch nicht welche
Sicherheitsmechanismen überhaupt notwendig bzw. ausreichend sind.
Vielmehr soll dies die Aufgabe des Deployers sein.




      4. Deklaratives Sicherheitsmodell der
                         EJB


   4.1 Der JBoss Application Server

Der JBoss Application Server ist ein J2EE konformer Open Source Server. Entwickelt
wurde er für die Umsetzung von Web- Applikationen mit Enterprise Java Beans.
Der JBoss Server kann frei von der Homepage des JBoss (www.JBoss.org)
heruntergeladen und verwendet werden. In dem Packet enthalten sind bereits alle
nötigen Bestandteile die für den Betrieb gebraucht werden:
    - Einen EJB Container
    - Einen Web Container (wahlweise Jetty oder Tomcat)
    - Eine Nachrichtenorientierte Middleware (JBoss MQ)
    - Eine einfache relationale Datenbank (Hypersonic SQL)

JBoss nutzt die Java Management Extension (JMX). Dieses dient zur Überwachung
und zur Administration von Java-Anwendungen zur Laufzeit. Jede zu Überwachende
Ressource wird dabei in MBeans (Managed Beans) gekapselt.
Der MBean-Server ist dabei der Vermittler zwischen den MBeans und den
Management Clients und bildet de n Kern des JBoss Application Servers.
Alle Dienste wie EJB-Container, Web-Container,              Transaktionsmanager,
Sicherheitsmanager, Verzeichnisdienst und Message Server, sind in ein MBean
eingebettet. So werden sie auf dem MBean-Server angemeldet.




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 13
Seminar Security Engeneering
                                                          Martin Kammerlander SS 2004




Abbil dung 3


Jeder Dienst kann andere Dienste, die er zur Erfüllung seiner Aufgaben benötigt,
über den MBean Server ansprechen (Service-Orientierte Architektur).
Die Dienste können dynamisch zur Laufzeit an- bzw. abgemeldet werden (Modularer
Aufbau).
Außerdem können die Dienste sogar zur Laufzeit, mit gewissen Management Tools,
konfiguriert werden (Dynamische Konfigurierbarkeit)

Der gesamte JBoss Application Server ist mit XML-Dateien konfigurierbar, frei nach
dem Motto der JBoss Entwickler: Verstecke so viel Komplexität vor dem Anwender
wie nur möglich.




4.2 Deklarative Sicherheit anhand des JBoss


Sicherheit ist ein fundamentaler Teil einer jeden Enterprise Applikation.
Es muss möglich sein festzulegen, wer die Berechtigung hat, auf die Applikationen
zuzugreifen und welche Operationen die User durchführen können.




4.2.1 Übersicht über die deklarative Sicherheit in J2EE

Das spezifizierte Sicherheitsmodell in J2EE, ist ein deklaratives Modell. Das heisst es
werden die Aspekte der Sicherheit weitgehend vom Code getrennt. Gründe dafür
sind, dass Security-Mechanismen nicht unbedingt (eigentlich gar nicht) etwas mit der
Businesslogik zu tun haben sollen. Vielmehr soll es die Aufgabe der lokalen
Deployment-Umgebung sein, die Sicherheitsmechanismen nachträglich festzulegen.
Einerseits bringt dies den einzelnen Komponenten eine hohe Wiederverwendung bei
 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 14
Seminar Security Engeneering
                                                         Martin Kammerlander SS 2004
zahlreichen anderen Projekten, andererseits wird je nach Verwendungszweck der
einzelnen Komponenten die Sicherheit mithilfe von Deployment-Deskriptoren, auf
das jeweilige Projekt genau zugeschnitten.
J2EE spezifiziert dazu ein simples Rollen-Basiertes (role-based) Sicherheitsmodell
für Web-Container und für die Java Enterprise Beans.


4.2.2 JBoss Securit y

Die JBoss Komponente die die Sicherheit am JBoss Application Server behandelt,
nennt sich das „JBossSX security framework“.
Die JBossSX security extension unterstützt einerseits das deklarative role-based
Modell der J2EE (JAAS), anderseits hat es eigene Sicherheitsmechanismen, die so
genannten „Security Proxy Layers“.
Die Security Proxy Layers haben den Nachteil, dass die Sicherheitseinstellungen
nicht über ein deklaratives Modell für eine Enterprise Bean festgelegt werden
können, sondern im EJB Business Object modelliert we rden müssen.


4.2.3 Java Aut hentification and Authorization Service (JAAS)

In Java sind die Zugriffsrechte abhängig von zwei Dingen: Woher wurde der Code
geladen, und wer hat den Code signiert. Dies nennt man das Codezentrierte
Sicherheitsmodell.
JAAS ist sozusagen eine Erweiterung dieses Sicherheitsmodells: Es wird gefragt,
wer den Code schlussendlich ausführt. Dies ist ein so genanntes Benutzerzentriertes
Sicherheitsmodell.
Notwendig wird JAAS, wenn man Multiuser- Applikationen betreiben will.
JAAS ist die Standard-Implementierung des in J2EE spezifizierten deklarativen
Sicherheitsmodells. Es wird dazu eingesetzt, User zu Authentifizieren und zu
Autorisieren.
Unter Authentifikation versteht man, dass der User erst den Beweis für seine Identität
erbringen muss, z.B. dadurch, dass er einen Benutzernamen mit dazugehörigem
Passwort eingeben muss.
Unter Autorisation hingegen versteht man, die Überprüfung der Zugriffrechte des
Benutzers; z.B. hat der Benutzer die ausreichenden Rechte eine bestimmte Aktion
auszuführen?




4.2.4 Wichtige Elemente der JAAS Implementierung

Mit den folgenden Konstrukten ist es möglich ein deklaratives Sicherheitskonzept in
JAAS umzusetzen:

4.2.4.1. Securit y References

Sind bereits im Code der Beans gewisse Rollen verankert (programmatisch), können
in den EJB’s (auch in Servlets) ein oder mehrere „security-role-ref“- Elemente
 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 15
Seminar Security Engeneering
                                                          Martin Kammerlander SS 2004
deklariert werden. Diese benötigt man um zu deklarieren dass eine Komponente den
„role-name“- Wert als ein Argument für die „IsCallerInRole(String)“- Methode nutzt.
Die Komponente ist mit dieser Methode nun in der Lage zu überprüfen ob ein „Caller“
eine Rolle hat, die mit Hilfe eines „security-rol-ref/role-name“- Element deklariert
wurde.
Das „role-name“- Element muss mithilfe von „role-link“ auf ein „security-role“-
Element gelinkt werden.
Die Methode „IsCallerInRole“ wird meistens verwendet wenn es nicht möglich ist
durch Methodenvergabe (über Deskriptoren) Sicherheitsmechanismen zu
modellieren.




Beispiel: Security References

<!-- A sample ejb-jar.xml fragment -->
<ejb-jar>
      <enterprise-beans>
            <session>
                  <ejb-name>ASessionBean</ejb-name>
                  ^^ ...
                  <security-role-ref>
                        <role-name>TheRoleICheck</role-name>
                        <role-link>TheApplicationRole</role-link>
                  </security-role-ref>
            </session>
      </enterprise-beans>
...
</ejb-jar>




4.2.4.2. Securit y Identit y

Man kann für EJB’s zusätzlich (optional) ein „security-identity“- Element deklarieren.
Bei der EJB 2.0 Spezifikation gibt es die Möglichkeit festzulegen welche Identität ein
Enterprise Bean annehmen soll, wenn es auf die Methoden von anderen
Komponenten, z.B. Im Container, zugreifen soll. Die „invocation-identity“ die Rolle
des aktuellen Callers sein, oder eine andere spezifische Rolle.
Der Application Assembler benutzt das „security-identity“- Element zusammen mit
dem „user-caller“- Child- Element um anzuzeigen, dass die Identität des aktuellen
Callers als Security Identität für die Methodenaufrufe der EJB’s benutzt werden
sollen.
Das Übertragen der Caller Identität ist ein Standard, falls es keine explizite
Deklaration einer „security-identity“ gibt.


Alternativ kann der Application Assembler auch das „run-as/role-name“-
Childelement benutzen um festzulegen, dass eine spezifische Security- Rolle, die der
„role-name“- Wert festlegt, als Security Identität genutzt wird. Wichtig dabei ist, dass
dabei nicht die eigentliche Identität des Callers verändert wird, sondern genau

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 16
Seminar Security Engeneering
                                                            Martin Kammerlander SS 2004
genommen werden die Security- Rollen des Callers auf eine Rolle gesetzt, die durch
den Wert des „run-as/role-name“- Elements festgelegt wird.
Eine Anwendung von „run-as“- Elementen ist z.B. dass sie verhindern, dass externe
Clients auf interne EJB’s zugreifen. Erreicht wird das dadurch, dass den internen
EJB’s so genannte „method-permissions“ zugewiesen werden. Diese begrenzen den
Zugriff nur auf jene Rollen, welche nicht einem externen Client zugewiesen sind. Die
EJB’s die eine interne EJB nutzen werden dann mit Hilfe der „run-as/role-name“
entsprechend konfiguriert.




                   Abbil dung 4
Zu Abbildung 4: Ein Aufruf kann einerseits direkt von einer Client- Anwendung kommen,
andererseits kann auch ein anderes EJB einen Aufruf starten. Vom Client aufgerufene EJB’s
verbreiten (propagieren) die Identität des Clients und zugeordnete Rollen zu anderen EJB’s,
welche aufgerufen werden.


Beispiel: Security Identity (ejb-jar.xml)

<!-- A sample ejb-jar.xml fragment -->
<ejb-jar>
      <enterprise-beans>
            <session>
                  <ejb-name>ASessionBean</ejb-name>
                  ...
                  <security-identity>
                  <use-caller-identity/>
                  </security-identity>
            </session>
            <session>
                  <ejb-name>RunAsBean</ejb-name>
                  ...
                        <security-identity>
                              <run-as>
                              <description>A private internal
                        role</description>
                              <role-name>InternalRole</role-name>
                              </run-as>
                        </security-identity>
            </session>
      </enterprise-beans>
      ...
</ejb-jar>


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 17
Seminar Security Engeneering
                                                         Martin Kammerlander SS 2004




4.2.4.3. Securit y Roles

Die Security Role Name wird durch die Elemente „security-rol-ref“ oder „security-
identity“ referenziert. Sie muss auf eine in der Applikation deklarierten Rolle
abgebildet werden. Durch die Deklarierung des „security-role“ Elements, definiert der
Application Assembler die logischen Security Roles.
Der Wert „role-name“ ist ein logischer Rollenname der in der Applikation enthalten ist
(Admin, User usw.).
Die Security Rollen im Deployment- Descriptor sollen dazu benutzt werden, um die
logische Security- Sicht auf eine Applikation zu definieren. Sie sollen nicht mit den
Konzepten Usergroups, User, Principals usw. die im „Target Enterprise's operational
Environment“ existieren, verwechselt werden.
JBoss verwendet eine Security- Role lediglich um die Werte von „security-roleref/
role-name“ auf die logische Rolle zu mappen, zu welcher der in der Komponente
deklarierte Rollenname gehört. Die Rollen, die dem Benutzer zugewiesen werden,
sind eine dynamische Funktion des Security Managers der Funktion.
Bei der Definition von Security- Rollen verlangt JBoss keine bestimmte Reihenfolge,
um die Rechte für die Methoden zu deklarieren.

Beispiel: Security Roles (ejb-jar.xml)


<!-- A sample ejb-jar.xml fragment -->
<ejb-jar>
...
      <assembly-descriptor>
            <security-role>
            <description>The single application role</description>
            <role-name>TheApplicationRole</role-name>
            </security-role>
      </assembly-descriptor>
</ejb-jar>



4.2.4.4. EJB Met hod Permissions

Der Application Assembler legt die Rollen fest, denen es erlaubt ist, Methoden des
EJB- Home und Remote- Interfaces aufzurufen. Dies geschieht dadurch, dass ein
„method-permission“- Interface deklariert werden muss.
Jedes „method-permission“- Element eines oder mehrere „role-name“-
Childelemente, die definieren, auf welche Art die logischen Rollen Zugriff auf die EJB
Methoden haben. Dies wird festgelegt durch die „method“- Child Elemente.

Beispiel: Method Permissions

<method-permission>
      <description>The employee role may access the
                  findByPrimaryKey, getEmployeeInfo, and the
                 updateEmployeeInfo(String) method of the

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 18
Seminar Security Engeneering
                                                       Martin Kammerlander SS 2004
                 AardvarkPayroll bean
      </description>
      <role-name>employee</role-name>
      <method>
            <ejb-name>AardvarkPayroll</ejb-name>
            <method-name>findByPrimaryKey</method-name>
      </method>
      <method>
            <ejb-name>AardvarkPayroll</ejb-name>
            <method-name>getEmployeeInfo</method-name>
      </method>
      <method>
            <ejb-name>AardvarkPayroll</ejb-name>
            <method-name>updateEmployeeInfo</method -name>
            <method-params>
                  <method-param>java.lang.String</method-param>
            </method-params>
      </method>
</method-permission>




Ab EJB 2.0 kann man nun ein „unchecked“- Element anstelle eines „role-name“-
Elements zu verwenden. Das „unchecked“- Element legt fest dass jeder
authentifizierte User auf jene Methoden zugreifen kann, die durch das „method“-
Childelement gekennzeichnet sind.
Das „exclude-list“- Element hingegen unterbindet hingegen jeglichen Zugriff auf die
Methoden.
Eine EJB Methode kann defaultmäßig nicht benutzt werden. Sie muss vorher durch
ein „method-permission“- Element für eine Rolle freigegeben werden.

Beispiel: unchecked
<method-permission>
      <description>Any authenticated user may
                    access any method of the
                    EmployeeServiceHelp bean
      </description>
      <unchecked/>
      <method>
            <ejb-name>EmployeeServiceHelp</ejb-name>
            <method-name>*</method-name>
      </method>
</method-permission>




Es gibt drei unterstützte Formen von „method“- Element Deklarationen:

   Form 1 wird benützt um alle home - und Komponenten- Interface Methoden des
    EJB’s zu anzusprechen:


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

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 19
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004
    </method>

   Form 2 wird benützt um eine spezielle home- und Komponenten- Interface
    Methode des EJB’s zu anzusprechen. Wenn es mehrere Methoden mit denselben
    Namen gibt (überladene Methoden), werden alle überladenen Methoden
    angesprochen:

    <method>
       <ejb-name>EJBNAME</ejb-name>
       <method-name>METHOD</method-name>
    </method>

   Form 3 spricht eine spezielle Methode und solche die denselben Namen besitzen,
    an. Die Methode muss im EJB home- oder remote- Interface definiert werden. Die
    „method-params“- Element Werte sind der volle Name des korrespondierenden
    Methoden Parameter Typs.
    Gibt es mehrere Methoden mit der selben überladenen Signatur, wird die
    Zugriffserlaubnis an alle Methoden gegeben.

    <method>
             <ejb-name>EJBNAME</ejb-name>
             <method-name>METHOD</method-name>
             <method-params>
                   <method-param>PARAMETER_1</method-param>
                   ...
                   <method-param>PARAMETER_N</method-param>
             </method-params>
    </method>




4.2.4.5. Web Cont ent Securit y Const raint s

In einer Webapplikation ist Sicherheit durch die Rollen definiert, die auf einen
geschützten Inhalt, der durch ein URL- Pattern eingegrenzt ist, zugreifen dürfen. Die
Festlegung dieser Parameter ist Gegenstand der Datei „web.xml“ und der sich in ihr
befindenden „security-constraint“- Elemente.
Der zu sichernde Inhalt ist durch das „web-resource-collection“- Element deklariert.
Jedes „web-resource-collection“- Element beinhaltet eine optionale Serie von „url-
pattern“- Elementen, gefolgt von einer optionalen Serie von „http-method“-
Elementen. Das „urlpattern“- Element spezifiziert ein URL-Pattern für einen
gesicherten Bereich. Eine angeforderte URL wird mit diesem Pattern verglichen, so
dass der Application Server den Zugriff auf einen restringierten Bereich erkenne n
kann (angeforderte URL entspricht dem Pattern). Das „http -method“ Element
spezifiziert die erlaubten HTTP-Anfragen (get, put...).

Das optionale „user-data-constraint“- Element spezifiziert die Anforderungen an den
Transport Layer der Client-Server Verbindung. Das „transport-guarantee“- Element
kann die Werte NONE, INTEGRAL oder CONFIDENTAL haben.
NONE bedeutet dass die Applikation keine Transportgarantie benötigt.
INTEGRAL bedeutet, Daten zwischen Server und Client so geschickt werden
müssen, dass sie nicht während des Transfers verändert werden.
CONFIDENTAL bedeutet, dass die Applikation sicher sein muss, dass die Daten die
geschickt werden nicht abgehört werden können.
Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 20
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004
In den meisten Fällen bedeutet INTEGRAL oder CONFIDENTAL, dass SSL benötigt
wird.

Das optionale „login-config“ wird benutzt, um die Authentifizierungsmethoden zu
konfigurieren, die der Server benutzen soll. Dieselben Aufgaben erfüllen der Realm
Name und die Attribute, die für den Form Login- Mechanismus benötigt werden. Das
„auth-method“- Childelement spezifiziert die Authentifizierungsmechanismen für die
Webapplikation. Als Voraussetzung für den Zugriff auf eine beliebige gesicherte
Webresource muss der Benutzer durch die eingerichteten Mechanismen
authentifiziert werden.

Beispiel: Web Content Security Constraints

  <web-app>
   ...
      <security-constraint>
      <web-resource-collection>
            <web-resource-name>Secure Content</web-resource-name>
            <url-pattern>/restricted/*</ url-pattern></
      <web-resource-collection>
      <auth-constraint>
            <role-name>AuthorizedUser</role-name>
      </auth-constraint>
      <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
      </user-data-constraint>
      </security-constraint>
      ...
      <login-config>
            <auth-method>BASIC</auth-method>
            <relam-name>The Restricted Zone</realm-name>
      </login-config>
      ...
      <security-role>
      <description>The role required to access restricted content
      </description>
            <role-name>AuthorizedUser</role-name>
      </security-role>
</web-app>




4.2.5 Was genau ist JAAS?


Die Standard- Implementation des JBoss SX frameworks basiert auf dem JAAS-
Application Programming Interface (API).
Da diese Implementation noch nicht sehr weit verbreitet ist, ist es wichtig, dass man
zuerst die grundlegenden Elemente des JAAS API versteht, um die Details des
JBoss SX verstehen zu können.


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 21
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004
Die JAAS 1.0 API besteht aus einer Menge von Java packages und wurde entworfen
um User am System zu Authentifizieren und zu Autorisieren. Sie implementiert eine
Java Version des Standard „Pluggable Authentication Module“ (PAM).
Die Idee von PAM ist, die Authentifzierung nicht in der Anwendung zu
programmieren, sondern in externe Module mit einer einheitlichen Schnittstelle
auszulagern. Das Authentifizierungsverfahren kann so sehr leicht durch das
Auswechseln der PAM- Module gewechselt werden.

Das JBoss SX Framework benützt lediglich die Authentifizierungsmöglichkeit des
JAAS um das deklarative Rollenbasierte J2EE Sicherheitsmodell zu implementieren.

Die JAAS Authentifizierung ist also sehr flexibel, da die Authentifizierungsmodule
einfach auswechselbar und zusätzlich kaskadierbar sind.
Vorteile davon sind:
     Java- Applikationen sind unabhängig von tiefer liegenden (Basis)
       Authentifizierungs- Technologien.
     Dem JBossSX- Security- Manager wird es ermöglicht in verschiedenen
       Sicherheitsumgebungen (Security- Infrastructures) zu arbeiten.
     Die Einbindung in eine Sicherheits- Infrastruktur kann ausgeführt werden,
       ohne die JBossSX- Security- Manager- Implementation zu verändern.
     Das Einzige was verändert werden muss, ist die Konfiguration des
       Authentifizierungs- Stacks, den JAAS verwendet.


4.2.5.1 Die JAAS Kern-(Core) Klassen

Die JAAS- Kernklassen werden in drei Kategorien aufgeteilt: In die „Common-“,
Authentifizierungs- und die Autorisierungs- Kategorien.
Es werden hier nur die Common- und die Authentifizierungs- Klassen behandelt, da
dies die spezifischen Klassen sind, um die Funktionalität des JBossSX zu
implementieren.



Common- Klassen:
      Subject (javax.security.auth.Subject)
      Principal (java.security.Principal)



Authentifizierungs- Klassen:
      Callback (javax.security.auth.callback.Callback)
      CallbackHandler (javax.security.auth.callback.CallbackHandler)
      Configuration (javax.security.auth.login.Configuration)
      LoginContext (javax.security.auth.login.LoginContext)
      LoginModule (javax.security.auth.spi.LoginModule)


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 22
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004


Subject und Principal:

Bevor die Benutzer autorisiert werden und sie schließlich auf gewisse Ressourcen
zugreifen können, muss zuerst die „Quelle“ der Anfrage authentifiziert werden. Als
Subject wird dabei z.B. der Benutzer bezeichnet, der die anfragende Quelle darstellt.
Die Subject- Klasse ist die Zentrale Klasse im JAAS. Das Subject repräsentiert die
Informationen einer einzelnen Entitäten, die eine Person oder ein Service sein kann.
Diese Informationen, beinhalten die Identitäte n, die als Principals bekannt sind.
Außerdem beinhalten sie Sicherheitsbezogene Attribute, genannt Credentials (z.B.
Zertifikate). Die JAAS API’s benützen das Java 2 java.security.Principal - Interface,
um ein Principal zu repräsentieren. Das Principal ist im Wesentlichen nur ein
zugeordneter Name, z.B. einer Person.

Während des Authentifizierungsprozesses wird ein Subject mit einer Identität, oder
einem Principal in Verbindung gebracht. Ein Subject kann mehrere Principals haben.
Als Beispiel, eine Person kann einen Principal Namen (John Doe), eine Principal
Sozialversicherungsnummer (123-45-6789) und einen Principal User- Namen
(johnd), haben. Alle diese Principals eines Subjects helfen dabei die verschiedenen
Subjects zu unterscheiden.


Um die Principals im Zusammenhang mit einem Subject wiederzufinden, gibt es die
zwei folgenden Methoden:


{
...
      public Set getPrincipals() {...}
      public Set getPrincipals(Class c){...}
}



Die erste Methode gibt alle Principals, die das Subject enthält, zurück.
Die zweite Methode gibt nur die Principals zurück, die Instanzen der Klasse c, oder
einer ihrer Subklassen sind.
Eine leere Menge wird zurückgegeben, wenn das Subject keine übereinstimmenden
Principals enthält.




4.2.6 Aut hentifizierung eines Subject s


Die Authentifizierung eines Subjects benötigt ein JAAS Login. Die Login Prozedur
besteht aus den nun folgenden Schritten:
   1. Die Applikation (Anwendung) erstellt einen LoginContext indem es den Namen
      der Loginkonfiguration an den CallbackHandler übergibt um die Callback
      Objekte zu füllen, wie es die LoginModules der Konfiguration verlangen.

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 23
Seminar Security Engeneering
                                                         Martin Kammerlander SS 2004
   2. Der LoginContext ruft eine Konfiguration auf um alle LoginModules zu laden,
      einschließlich den Namen der Loginkonfiguration. Existiert keine solche
      „named- configuration“ wird die „andere“ Konfiguration als Default-
      Konfiguration hergenommen.
   3. Die Applikation ruft die LoginContext.login auf.
   4. Die Login Methode ruft alle geladenen LoginModules auf. Jedes LoginModule
      versucht das Subject zu authentifizieren. Es ruft dabei die handle Methode auf
      dem dazugehörigen CallbackHandler auf, um die benötigten Informationen für
      den Authentifizierungsprozess zu erhalten.
      Die benötigten Informationen durchlaufen die handle Methode in Form eines
      Arrays von Callback Objekten. Bei Erfolg, ordnen die LoginModules alle
      relevanten Principals und Credentials dem passenden Subject zu.
   5. Der LoginContext gibt den Authentifizierungsstatus an die Applikation zurück.
      Bei Erfolg, gibt es eine Rückgabe von der login Methode. Ein Fehler ist
      dadurch gekennzeichnet, dass die login Methode eine LoginException wirft.
   6. Wenn Authentifizierung erfolgt, erhält die Applikation das authentifizierte
      Objekt über die LoginContext.getSubject Methode.
   7. Nachdem die Subject Authentifizierung abgeschlossen ist, werden alle
      Principals und jede verbundene Information mit dem Subject, über die login
      Methode, entfernt. Das geschieht mit dem Aufruf der LoginContext.logout
      Methode.


Die Klasse LoginContext bietet die Basis- Methoden für die Authentifikation eines
Subjects. Sie bietet die Möglichkeit eine Applikation zu entwickeln, die unabhängig
von der tieferliegenden Authentifikations- Technologie ist. Der LoginContext ruft eine
Configuration auf, um den Authentifizierungs- Service zu beenden.
Die LoginModules Klassen repräsentieren den Authentifizierungs- Service.
Deswegen ist es möglich, die einzelnen LoginModules              in einer Applikation
auszutauschen, ohne die Applikation selbst zu verändern.
Die Entwickler integrieren eine Authentifikations- Technologie, indem sie ein
LoginModule Interface programmieren. Somit können verschiedene Authentifikations-
Technologien vom Administrator in eine Applikation eingebaut oder
herausgenommen werden.
Mehrere LoginModules können zusammengeschlossen werden, damit mehrere
Authentifikations- Technologien Teil des Authentifikations- Prozesses sein können.
Als Beispiel: Ein LoginModule führt einen Username-Password basierten
Authentifikations- Prozess durch, ein anderes Modul hingegen benützt eine mit Smart
Card oder biometrische Authentifikation.
Der Lebenszyklus eines LoginModules wird gesteuert vom LoginContext Objekt
gegen welches der Client eine login Methode erzeugt und ausgibt.

Die einzelnen Schritte des Prozesses:
   1. Der LoginContext erzeugt jedes konfigurierte LoginModule über seinen
       Konstruktor.
   2. Jedes LoginModule wird initialisiert indem es die initial Methode aufruft. Beim
       Subject Argument muss die Garantie gegeben sein dass es nicht Null ist. Die
       initialize Methode sieht folgendermaßen aus:
       callback-public      void     initialize(Subject subject,     CallbackHandler
       callbackHandler, Map sharedState, Map options);
 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                                  SX Security Extension
                                                                              Seite 24
Seminar Security Engeneering
                                                          Martin Kammerlander SS 2004
   3. Die login Methode wird beim Start des Authentifikations- Prozesses
      aufgerufen. Die Methode befragt den User nach Benutzernamen und
      Passwort und verifiziert die eingegebenen Daten mit den Daten die in den
      „naming- services“ gespeichert sind. Andere Möglichkeiten wären natürlich
      Smartcards, biometrische Daten oder einfach das auslesen der User
      Informationen aus dem darunterliegenden Betriebssystems. Die Verifizierung
      der User- Identität durch die Verschiedenen LoginModules wird auch als die
      Phase 1 der JAAS Authentifikation bezeichnet. Die login Methode sieht
      folgendermaßen aus: boolean login() throws LoginException;
      Es wird also eine Exception geworfen falls der Rückgabewert „false“ ist.
   4. Wenn Phase 1 erfolgreich war, wird die commit Methode auf jedem
      LoginModule aufgerufen. Dann beginnt commit mit der Phase 2: Sie verknüpft
      alle relevanten Principals und Credentials mit dem Subject. Schlägt Phase 1
      fehl, dann löscht die Methode commit den Vohergegangen gespeicherten
      Authentifikationsstatus, wie Username und Passwort. Die commit Methode
      sieht folgendermaßen aus: boolean commit() throws LoginException;
      Es wird also eine Exception geworfen falls der Rückgabewert „false“ ist.
   5. Wenn LoginContext Authentifizierung fehlschlägt, wird die abort Methode auf
      dem LoginModule aufgerufen. Die abort Methode löscht bzw. zerstört jeden
      Authentifikationsstatus, der von der login oder initialize. Die abort Methode
      sieht folgendermaßen aus: boolean abort() thro ws LoginException;
      Es wird also eine Exception geworfen falls der Rückgabewert „false“ ist.
   6. Nach einem erfolgreichen Login wenn sich der User wieder ausloggen will, ruft
      die Applikation die Methode logout auf dem LoginContext auf. Auf jedem
      LoginModule wird ein logout aufgerufen. Die logout Methode trennt die
      verbundenen Principals und Credentials, die mit dem Subject
      zusammenhängen. Credentials sollten nach der Trennung gelöscht werden.
      Die logout Methode sieht folgendermaßen aus: boolean logout() throws
      LoginException;
      Es wird also eine Exception geworfen falls der Rückgabewert „false“ ist.


Wenn ein LoginModule mit einem User „kommuniziert“, um die Authentifikations-
Informationen zu erhalten, benützt es ein CallbackHandler Objekt. Die Applikationen
implementieren ein Callback- Interface und geben es dem LoginContext weiter.
Dieser gibt es den darunterliegenden LoginModules.LoginModules weiter welche
auch den CallbackHandler benutzen um Informationen über den User zu sammeln
(z.B. Password, Pin-Nummer usw.) und dem User z.B. Statusinformationen zu
geben. Wenn die Applikation den CallbackHandler spezifiziert, dann bleiben die
darunterliegenden LoginModules unabhängig von den verschiedenen Möglichkeiten
wie die Applikationen mit dem User kommunizieren. Als Beispiel kann man eine GUI
Applikation nehmen: sie stellt ein Fenster dar in dem der User seine Daten
(Username, Passwort) eingeben kann. Anderseits gibt es natürlich auch
CallbackHandler Implementierungen für eine nicht GUI Umgebung, wie z.B. für einen
Application- Server der einfach nur Credentials (Zertifikate) als Informationen erhält.
Das CallbackHandler Interface implementiert eine Methode:

void handle(Callback[] callbacks) throws java.io.IOException,
UnsupportedCallbackException;

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 25
Seminar Security Engeneering
                                                                        Martin Kammerlander SS 2004
Das Callback Interface unterstützt sehr viele Standard Implementationen dazu
gehören NameCallback und PasswordCallback. Die LoginModules verwenden den
Callback um Informationen abzufragen, die für den Authentifizierungs - Mechanismus
wichtig sind. Die LoginModules übergeben der Methode CallbackHandler.handle
einen Array von Callbacks, während der Authentifizierungs- Phase Login. Wenn der
CallbackHandler nicht versteht wie er ein Callback- Objekt verwenden soll, so wirft er
eine UnsupportedCallbackException um den Methodenaufruf login zu unterbrechen.




                   5. Das JBoss Security Model
Die Interfaces die den JBoss Server Security Layer sind folgende:
    org.jboss.security.AuthenticationManager
    org.jboss.security.RealmMapping
       org.jboss.security.SecurityProxy




Abbil dung 5: Das Sicherheitsmodell des JBoss
Die hell blauen Kl assen stellen die Security Interfaces dar, die repräsentieren den EJB Container Layer

5.1 Security Interfaces


Die Einzelnen Security Interfaces:


 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 26
Seminar Security Engeneering
                                                                  Martin Kammerlander SS 2004
      Das AuthenticationManager Interface ist verantwortlich für die Validierung der
       Credentials die wiederum mit den Principals zusammenhängen. Die IsValid
       Methode wird aufgerufen um zu überprüfen, ob die User- Identität und die
       dazugehörigen Credentials Gültigkeit haben.
      Das RealmMapping Interface ist verantwortlich für das Principal- und das
       Role- Mapping. Die GetPrincipal Methode benötigt eine Identität, die in der
       Umgebung bekannt ist, und gibt die Applikations- Domain- Identität zurück.
       Die doesUserHaveRole Methode validiert ob die User Identität der Rolle der
       Application- Domain zugeordnet wurde.
      SecurityProxy ist ein Interface, welches ein SecurityProxyInterceptor Plug-inn
       benötigt. Ein SecurityProxy erlaubt die Externalisierung von verschiedenen
       Sicherheits- Checks auf der Basis der „per-method“ für das EJB Home und
       den Remote- Interfaces.
      Der SubjectSecurityManager ist ein Sub-Interface des
       AuthenticationManagers und fügt Methoden hinzu, um den Security Domain
       Name des Security Managers und das Authentifizierte Subject zu
       Überwachen.
      Die SecurityDomain ist eine Erweiterung (extends) des AuthenticationManager
       des RealMapping und des SubjectSecurityManager Interfaces. Es wird eines
       Tages die Basis für eine Multi-Domain Sicherheits-Architektur sein.

Das JBoss Security Framework ist eine einfache Implementation der Basis
Sicherheits-Plugins die auf JAAS basieren. Diese Implementation ermöglicht es,
auch eine eigene Security Manager Implementation vorzunehmen, die JAAS nicht
nutzt.




Abbil dung 6: Die Beziehungen zwischen dem JB ossSX Framework Kl assen und dem JB oss Server EJB
Container Layer

Um Sicherheit im JBoss zu anzuwenden, braucht es die Spezifischen Deployment-
Deskriptoren. Abbildung 7 zeigt die JBoss spezifischen EJB und Web Applikationen
Elemente der Deskriptoren


Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 27
Seminar Security Engeneering
                                                                      Martin Kammerlander SS 2004




Abbil dung 7: Die J boss.xml und die J boss -web.xml Depl oyment Deskriptoren



Die Wert der Security Domain wird durch das „Java Naming and Directory“ (JNDI)
festgelegt. Wird das Objekt als Top-Level-Element festgelegt, so definiert dies für alle
EJB’s in der Deployment Einheit die Security Domain.
Um die Security Domain für ein einzelnes EJB festzulegen, muss man die Security
Domain am Container des EJB angeben. Wird das gemacht, so wird das Top-Level
Security Element überschrieben.

Das unauthenticated-principal gibt den Namen des Principals an das verwendet
werden soll (Rückgabe des Namens: EJB.Context.getUserPrincipal), wenn ein nicht
authentifizierter User auf ein EJB zugreifen möchte. Einem nicht authentifizierten
Aufrufer gibt dies aber keine speziellen Berechtigungen. Gebraucht wird dies, wenn
z.B. ein nicht bekanntes (unsicheren) Servlet Zugriff auf nicht gesicherte EJB’s zu
geben. Ausserdem besitzt das EJB ein Principal, dass nicht Null ist.
 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 28
Seminar Security Engeneering
                                                      Martin Kammerlander SS 2004


Das Security Proxy Element wird verwendet, wenn die deklarative
Sicherheitsbeschreibung nicht ausreicht.      Es kann eine Implementation des
org.jboss.security.SecurityProxy Interfaces, oder aber einfach ein Objekt, das
Methoden in den Interfaces der EJB’s implementiert, sein.
Ein einfaches Beispiel eines SecurityProxy im Zusammenhang mit einem stateless
Session Beans: Das SecurityProxy stellt sicher, dass keiner die Echo Bean Methode
aufruft, mit einem Vier-Buchstaben-Wort als Argument. Ein solcher Check wäre
unmöglich mit einer Rollen- basierten Sicherheit. Mann kann keine
FourLetterEchoInvoker Rolle definieren, weil der Sicherheits-Kontext das Methoden
Argument und nicht eine Eigenschaft des Aufrufenden ist.



   5.2 Beispiel EchoSecurityProxy

Ein Beispiel einer Implementation eines EchoSecurityProxy anhand des echo-
argument basierten Sicherheits Constraints.




package org.jboss.chap8.ex1;
import java.lang.reflect.Method;
import javax.ejb.EJBContext;
import org.apache.log4j.Category;
import org.jboss.security.SecurityProxy ;
/** A simple example of a custom SecurityProxy implementation that
demonstrates method argument based security checks.
 * @author Scott.Stark@jboss.org
@version $Revision:$
*/
public class EchoSecurityProxy implements SecurityProxy
{
      Category log = Category.getInstance(EchoSecurityProxy.class);
      Method echo;
      public void init(Class beanHome, Class beanRemote,
            Object securityMgr)
            throws InstantiationException
      {
            log.debug("init, beanHome="+beanHome
                  + ", beanRemote="+beanRemote
                  + ", securityMgr="+securityMgr);
            // Get the echo method for equality testing in invoke
            try
            {
                  Class[] params = {String.class};
                  echo = beanRemote.getDeclaredMethod("echo", params);
            }
            catch(Exception e)
            {
                  String msg = "Failed to finde an echo(String) method";
                  log.error(msg, e);
Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 29
Seminar Security Engeneering
                                                        Martin Kammerlander SS 2004
                    throw new InstantiationException(msg);
             }
      }
      public void setEJBContext(EJBContext ctx)
      {
            log.debug("setEJBContext, ctx="+ctx);
      }
      public void invokeHome(Method m, Object[] args)
            throws SecurityException
      {
      // We don't validate access to home methods
      }
      public void invoke(Method m, Object[] args, Object bean)
            throws SecurityException
      {
            log.debug("invoke, m="+m);
            // Check for the echo method
            if( m.equals(echo) )
            {
                  // Validate that the msg arg is not 4 letter word
                  String arg = (String) args[0];
                  if( arg == null || arg.length() == 4 )
                  throw new SecurityException("No 4 letter words");
            }
            // We are not responsible for doing the invoke
      }
}




Ein Beispiel für den jboss.xml Deskriptor, das die EchoSecurityProxy als das
Standard Sicherheits-Proxy für fas Echo Bean angibt:


<jboss>
      <security-domain>java:/jaas/other</security-domain>
      <enterprise-beans>
            <session>
                  <ejb-name>EchoBean</ejb-name>
                  <security-proxy>org.jboss.chap8.ex1.EchoSecurityProxy
                  </security-proxy>
            </session>
      </enterprise-beans>
</jboss>




Gezeigt werden soll mit diesem Beispiel, dass es möglich und auch notwendig ist,
auch ohne das deklarative Modell, die Sicherheit unabhängig von der Bean
Implementation durchzuführen.




Im Testhauptprogramm, versucht ein Client die EchoBean.echo Methode mit den
Argumenten „Hello“ und „Four“ aufzurufen:

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 30
Seminar Security Engeneering
                                                            Martin Kammerlander SS 2004


public class ExClient
{
      public static void main(String args[]) throws Exception
      {
            Logger log = Logger.getLogger("ExClient");
            log.info("Looking up EchoBean");
            InitialContext iniCtx = new InitialContext();
            Object ref = iniCtx.lookup("EchoBean");
            EchoHome home = (EchoHome) ref;
            Echo echo = home.create();
            log.info("Created Echo");
            log.info("Echo.echo('Hello') = "+echo.echo("Hello"));
            log.info("Echo.echo('Four') = "+echo.echo("Four"));
      }
}


Der erste Aufruf („Hello”) ist erfolgeich. Der Zweite Aufruf („Four“) schlägt fehl, da es
ein 4 Worte Wort ist. Es wird also eine Exception geworfen.




              6. JBoss SX Security Extension

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 31
Seminar Security Engeneering
                                                             Martin Kammerlander SS 2004
Das Herz des JBoss SX Frameworks ist der org.jboss.security.plugins.JaasSecurity-
Manager. Das ist die Default- Implementation des AuthenticationManagers und des
RealmMapping Interfaces.




Abbil dung 8: Hier sehen wir den Zusammenhang zwischen der Security Domain , dem Komponenten
Container und dem JaasSecurityManagers




Abbildung 8 zeigt eine Enterprise Applikation die den EJB- und Web- Inhalt unter der
Security Domain „jwdomain“, gesichert hat. Zur Deployment Zeit besitzt das Security
Domain Element in den jboss.xml und jboss-web.xml, den Wert der Security
Manager Instanz, die mit dem Container in Verbindung steht. Der Security Interceptor
benutzt dann den Security Manager um seine Rolle auszuführen. Wenn eine
Sichere Komponente angefragt wird, erlaubt der Security Interceptor dem Security
manager die Sicherheit zu checken.

Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 32
Seminar Security Engeneering
                                                                        Martin Kammerlander SS 2004


Der jBossSX JaasSecurityManager, führt die Sicherheits-Checks basierend auf den
Informationen, die mit dem Subject verbunden sind, aus.




6.1 Wie benützt der JaasSecurityManager JAAS?

Der JaasSecurityManager erhält sein Verhalten von der Ausführung der Login Modul
Instanzen die unter dem Namen der Security Domain konfiguriert sind. Die Login
Module implementieren die Security Domain Principal Authentifizierung und das
Role-Mapping Verhalten. Verschiedene Security Domains könne n einfach durch den
JaasSecurityManager genützt werden, indem man verschiedene Login Module
Konfigurationen Einfügt oder entnimmt.




Abbil dung 9: Invol vierte Schritte bei der Authenti fikation und der Autorisati on eines geschützten EJB
Home Methoden Aufrufs


    1. Zuerst muss der Client eine JAAS Login ausführen, um die Principals und die
       Credentials zu erhalten. Es wird eine LoginContext Instanz erzeugt und es

 Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                             SX Security Extension
                                                                           Seite 33
Seminar Security Engeneering
                                                         Martin Kammerlander SS 2004
      wird der Name der Konfiguration (hier „other“) übergeben. Diese einmalige
      Login verbindet die Principals und die Credentials mit allen EJB
      Methodenaufrufen.
      Hier wird das default Client Modul benützt, das einfach den Usernamen und
      das Passwort an den JBoss EJB Layer bindet, für die spätere
      Authentifizierung am Server.
   2. Später erhält der Client das EJB Home Interface und versucht einen Bean zu
      kreieren (Home Method Invocation). So kommt es zu einem Aufruf einer Home
      Interface Methode die an den JBoss Server geschickt wird. Der Aufruf
      beinhaltet alle Methoden Argumente (User Identität, Credentials) des Client-
      Seitigen JAAS Logins.
   3. Auf der Server-Seite benötigt der Security Interceptor die Authentifizierung des
      Users der die Methode aufrufen will.
   4. Die Security Domain, unter welcher das EJB geschützt ist, ermittelt die Wahl
      des Login Moduls. Der Security Domain Name wird als Login Konfigurations -
      Name an den LoginContext Konstruktor übergeben. Wenn die JAAS Login
      den User Authentifiziert hat, wird ein JAAS Subject kreiert.




Quellen:


-JBoss Dokumentation
-www.lexitron.de
-http://www.fh-wedel.de/~si/seminare/ws00/Ausarbeitung/10.ejb/pages/ejb3.htm
-http://www.inform.fh-hannover.de/file_doku/ejbForGiBraunschweig.pdf
-http://www.infosys.tuwien.ac.at/Teaching/Courses/SWV/slides/reuse03-comp-
mod.pdf
-http://www.adnovum.ch/pdf/iex03_tm_j2ee_security.pdf
-http://139.18.4.97/docs/06.pdf




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 34
Seminar Security Engeneering
                                                      Martin Kammerlander SS 2004




Thema: J2EE – Deklaratives Sicherheitsmodell der EJB 2.0 am Beispiel der JBOSS
                            SX Security Extension
                                                                          Seite 35

								
To top