Instanzbasierte Zugriffsmechanismen für EJB-basierte Datenbankanwendungen

Röller, Ronny

Instanzbasierte Zugriffsmechanismen für EJB-basierte Datenbankanwendungen

Zusammenfassung

Inhaltsangabe:Zusammenfassung:
Das Sicherheitsmodell der EJB-Plattform basiert ausschliesslich auf der Struktur der zu schützenden Beans, nicht auf deren Inhalt. So ist es nicht möglich, den Zugriff auf eine Methode abhängig von Beandaten oder der übergebenen Methodenparameter zu erlauben/zu verwehren.
Es wurde eine Erweiterung des existierenden EJB-Sicherheitsmodells entwickelt. Mangels Spezifikation ist diese Lösung nur EJB-Server spezifisch möglich. Dafür wurde der Opensource-EJB-Server JBoss gewählt, auf dessen Securityproxys die erstellte Lösung aufsetzt. Mittels der entwickelten Klassenbibliothek kann die Regelbasis in einer Datenbank hinterlegt und ausgewertet werden. Für die Regeldefinition können auf die Daten des zu schützenden Beans, des aufrufenden Principles und die übergebenen Methodenparameter zugegriffen werden. Die einzelnen atomaren Regeln können logisch verknüpft werden, um auch komplexe Anwendungsfälle adäquat abzubilden.
Die Klassenbibliothek wurde anwendungsneutral entwickelt und abschliessend im Rahmen des Prüfungsverwaltungssystems jExam erfolgreich getestet.

Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Einleitung1
2.Sicherheitskonzepte für Java und EJB3
2.1Übersicht über die Sicherheitskonzepte3
2.1.1Sicherheitskonzepte zum Schutz von Klienten3
2.1.2Sicherheitskonzepte zum Schutz von Servern4
2.2Sicherheitsmechanismen in Java6
2.2.1Java 27
2.2.2Java Authentication and Authorization Service8
2.3Sicherheit für Enterprise Javabeans10
2.3.1Historischer Abriss10
2.3.2Programmierorientierte und deklarative Sicherheit11
2.3.3EJB 2.0-Deskriptoren für deklarative Sicherheit12
2.4Kritik an verfügbaren Sicherheitsmechanismen14
2.5Zusammenfassung15
3.Sicherheitsmechanismen im Jboss17
3.1Opensource-EJB-Server JBoss17
3.2Security Manager und Security Manager Service18
3.3Erweiternder Securityproxy19
3.4Architektur des gewählten Ansatzes23
3.5Zusammenfassung24
4.Entwurf eines Regelsystem25
4.1Atomare Regeln und Verbindungsregeln25
4.2Atomare Regeln26
4.2.1Operanden26
4.2.2Rekursive Operanden28
4.2.3Kollektionen als Operanden30
4.2.4Operatoren30
4.2.5Umsetzung in der Datenbank31
4.3Regelsystem31
4.3.1Grundsätzlicher Aufbau31
4.3.2Geordneter Binärbaum32
4.3.3Regelbaum33
4.3.4Regelpyramide35
4.4Regelsystem der Klassenbibliothek41
4.5Zusammenfassung41
5.Implementierung und Integration43
5.1Implementierung der Klassenbibliothek43
5.1.1Erweiterungen43
5.1.2Weitere […]

Leseprobe

Inhaltsverzeichnis

ID 6963

Röller, Ronny: Instanzbasierte Zugriffsmechanismen für EJB-basierte

Datenbankanwendungen

Hamburg: Diplomica GmbH, 2003

Zugl.: Fachhochschule Südwestfalen, Technische Universität, BA-Thesis / Bachelor, 2003

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2003

Printed in Germany

Inhaltsverzeichnis

Einleitung

Sicherheitskonzepte für Java und EJB

2.1

Übersicht über die Sicherheitskonzepte

. . . . . . . . . . . .

2.1.1

Sicherheitskonzepte zum Schutz von Klienten

. . . .

2.1.2

Sicherheitskonzepte zum Schutz von Servern

. . . . .

2.2

Sicherheitsmechanismen in Java

. . . . . . . . . . . . . . . .

2.2.1

Java 2

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2

Java Authentication and Authorization Service

. . . .

2.3

Sicherheit für Enterprise Javabeans

. . . . . . . . . . . . . . .

2.3.1

Historischer Abriss

. . . . . . . . . . . . . . . . . . . .

2.3.2

Programmierorientierte und deklarative Sicherheit

2.3.3

EJB 2.0-Deskriptoren für deklarative Sicherheit

. . . .

2.4

Kritik an verfügbaren Sicherheitsmechanismen

. . . . . . . .

2.5

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . .

Sicherheitmechanismen im JBoss

3.1

Opensource-EJB-Server JBoss

. . . . . . . . . . . . . . . . . .

3.2

SecurityManager und SecurityManagerService

. . . . . . . .

3.3

Erweiternder Securityproxy

. . . . . . . . . . . . . . . . . . .

3.4

Architektur des gewählten Ansatzes

. . . . . . . . . . . . . .

3.5

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . .

Entwurf eines Regelsystem

4.1

Atomare Regeln und Verbindungsregeln

. . . . . . . . . . . .

4.2

Atomare Regeln

. . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1

Operanden

. . . . . . . . . . . . . . . . . . . . . . . .

4.2.2

Rekursive Operanden

. . . . . . . . . . . . . . . . . .

4.2.3

Kollektionen als Operanden

. . . . . . . . . . . . . . .

4.2.4

Operatoren

. . . . . . . . . . . . . . . . . . . . . . . .

4.2.5

Umsetzung in der Datenbank

. . . . . . . . . . . . . .

4.3

Regelsystem

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1

Grundsätzlicher Aufbau

. . . . . . . . . . . . . . . . .

4.3.2

Geordneter Binärbaum

. . . . . . . . . . . . . . . . . .

4.3.3

Regelbaum

. . . . . . . . . . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

4.3.4

Regelpyramide

. . . . . . . . . . . . . . . . . . . . . .

4.4

Regelsystem der Klassenbibliothek

. . . . . . . . . . . . . . .

4.5

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . .

Implementierung und Integration

5.1

Implementierung der Klassenbibliothek

. . . . . . . . . . . .

5.1.1

Erweiterungen

. . . . . . . . . . . . . . . . . . . . . .

5.1.2

Weitere Implementationsentscheidungen

. . . . . . .

5.2

Integration in jExam

. . . . . . . . . . . . . . . . . . . . . . .

5.2.1

Szenario PlanningMgr

. . . . . . . . . . . . . . . . . .

5.2.2

Programmierung des Securityproxy

. . . . . . . . . .

5.2.3

Regeldefinition

. . . . . . . . . . . . . . . . . . . . . .

5.2.4

Nutzung

. . . . . . . . . . . . . . . . . . . . . . . . . .

5.3

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . .

Ausblick und Zusammenfassung

6.1

Mögliche Erweiterungen

. . . . . . . . . . . . . . . . . . . . .

6.2

Zusammenfassung

. . . . . . . . . . . . . . . . . . . . . . . .

Abbildungsverzeichnis

Quelltextverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

Kurzfassung

Die Enterprise Javabean Plattform bietet nur rollenbasierende Sicherheits-

mechanismen eine Konzept, das in komplexen Anwendungen schnell

an seine Grenzen führt. Ein existierender Ausweg ist der Verzicht auf die

deklarativen Mittel von EJB und die direkte Programmierung in dem zu

schützenden Bean. Dieses Vorgehen widerspricht aber der Trennung von

Geschäfts- und Sicherheitslogik und ist deshalb nicht wünschenswert. Viel-

mehr wird ein instanzbasierendes Sicherheitsmodell gesucht, das soweit

wie möglich deklarativ programmiert werden kann.

In der vorliegenden Arbeit werden die existierenden Sicherheitsme-

chanismen von Java und EJB auf ihre Tauglichkeit untersucht. Dabei stellt

sich heraus, dass mangels Spezifizierung des instanzbasierenden Sicher-

heitsmodells für die EJB-Plattform nur ein EJB-Server-spezifischer Weg in

Frage kommt. Der Opensource-EJB-Server JBoss bietet eine dahingehen-

de Unterstützung mittels Securityproxys, die nach dem standardmäßigen

rollenbasierenden Test ausgeführt werden.

Darauf basierend wird eine entwickelte Klassenbibliothek beschrieben,

die die Programmierung von entsprechenden Proxys extrem vereinfacht.

Die Zugriffsregeln werden in einer relationalen Datenbank hinterlegt, aus

der die Klassenbibliothek diese auslesen und auswerten kann. Im Rahmen

der Arbeit werden verschiedene Ansätze für das benötigte Regelsystem

diskutiert. Als kritische Eckpunkte kristallisieren sich Flexibilität und Ro-

bustheit heraus. Deshalb wird ein mehrschichtiges Modell gewählt, das

atomare Regeln im Bereich der Aussagenlogik verknüpft.

Exemplarisch wurde die Klassenbibliothek in das Studentenverwal-

tungssystem jExam der Fakultät Informatik, TU Dresden integriert. Die

Beans im jExam-System sollen im Rahmen der weiteren Entwicklung durch-

gängig durch das innerhalb der vorliegenden Arbeit entwickelte Sicher-

heitssystem geschützt werden.

iii

Kapitel 1

Einleitung

Die zunehmende Komplexität von Softwareanwendungen erfordert neue

Entwicklungsmethoden wie beispielsweise der Einsatz von komponente-

norientiertenden Plattformen. Herauszuheben ist dabei die Enterprise Ja-

vabean Plattform der Firma Sun Microsystems.

Auf dieser EJB-Plattform wurde an der Technischen Universität Dres-

den das jExam-System zur Studienbetreuung der Informatikstudenten ent-

wickelt. Mittlerweile besteht ein großes Interesse anderer Fakultäten und

Universitäten an diesem System, so dass sich der Nutzerkreis in näch-

ster Zeit stark erweitert wird. Dadurch gewinnt auch der Faktor Sicher-

heit eine noch größere Bedeutung. Neben Sicherheit auf technischer Ebe-

ne werden auch Schutzmechanismen auf Anwendungsebene eingesetzt.

Im Rahmen der vorliegenden Arbeit werden nur letztere betrachtet. Das

bis dato eingesetzte rollenbasierende Sicherheitssystem kann diesen neu-

en Herausforderungen nicht mehr gerecht werden. Hieraus entstand der

Wunsch, ein instanzbasierendes Sicherheitssystem einzusetzen. Dies ist

momentan nur mit Hilfe von programmierorientierten Methoden in En-

terprise Javabeans möglich. Die Abkehr von der deklarativen Program-

mierung unterläuft aber einige der Grundkonzepte von EJB. Als wün-

schenswert erscheint ein instanzbasierendes Sicherheitssystem, das wei-

terhin Geschäfts- von Sicherheitslogik trennt. Diese Lücke zu schließen,

stellt Ziel dieser Bakkalaureatsarbeit dar.

Im zweiten Kapitel wird ein Überblick über die fügbaren Sicherheits-

mechanismen von Java und EJB gegeben und diese kritisiert. Daraus er-

geben sich dann die Überlegungen der folgenden Kapitel. Kapitel drei

beschäftigt sich mit den technischen Aspekten der JBoss-spezifischen Lö-

sung; Kapitel vier legt das Augenmerk auf die Logik der zu entwickelnden

Klassenbibliothek. Im Kapitel fünf wird die Implementierung der Klassen-

bibliothek erläutert und die Lösung exemplarisch in das jExam-System

integriert. Im abschließenden sechsten Kapitel werden mögliche Erweite-

rungen diskutiert.

Kapitel 2

Sicherheitskonzepte für Java und

EJB

In diesem Kapitel werden verschiedenen Sicherheitskonzepte zunächst

theoretisch betrachtet und dann ihre Umsetzung in der Programmierspra-

che Java, sowie in der komponentenorientierten Architektur Enterprise

Javabeans untersucht. In der Diskussion der existierenden Sicherheitsme-

chanismen werden Schwachstellen aufgezeigt, die im Rahmen der weite-

ren Arbeit beseitigt werden.

2.1

Übersicht über die Sicherheitskonzepte

Es gibt diverse Möglichkeiten, nach denen Sicherheitsmechanismen klas-

sifiziert werden können wie beispielsweise das zu Grunde liegende Ob-

jekt, um Zugriffsentscheidungen auszuwerten. Über diese wird im Fol-

genden ein Überblick gegeben.

Zur Veranschaulichung wird das folgende durchgängige Szenario her-

angezogen: Auf der Website eines Bankunternehmens befindet sich ein Ja-

va-Applet für das Online-Banking. Mit diesem Applet können Kunden ih-

ren Finanzstatus abrufen und Überweisungen auslösen. Desweiteren kön-

nen Bankangestellte im Außendienst Informationen ihrer Kunden einse-

hen.

2.1.1

Sicherheitskonzepte zum Schutz von Klienten

Codebase-basierende Sicherheitsmechanismen:

Die Codebase bezeich-

net den Ort, von dem aus der Code geladen wird. In dem skizzier-

ten Szenario ist das die Domain des Kreditinstitutes. Der Nutzer am

heimischen PC kann seinem Webbrowser beispielsweise die Ausfüh-

rung aller Java-Applets verbieten. Da er aber die Bank als vertrau-

enswürdig einstuft, macht er eine Ausnahme und erlaubt allen Ap-

plets, die von der Domain http://www.bank.com geladen werden,

KAPITEL 2. SICHERHEITSKONZEPTE FÜR JAVA UND EJB

die Nutzung seiner Ressourcen.

Der Codebase-basierende Mechanismus wird in den marktbeherr-

schenden Webbrowsern nur sehr mangelhaft implementiert und ist

deshalb relativ einfach zu überwinden. Es sind zahlreiche Angriffe

bekannt, wie einem Webbrowser suggeriert werden kann, dass ein

Applet aus einer anderen Domain stammt. Außerdem garantiert na-

türlich die Existenz in einer bestimmten Domain noch nicht automa-

tisch die Vertrauenswürdigkeit einer Anwendung. Umgekehrt kann

auch der gleiche vertrauenswürdige Code auf verschiedenen Domä-

nen gespeichert sein.

Signaturbasierende Sicherheitsmechanismen:

Ein Ausweg aus diesem

Missstand sind Signaturen. Der Kunde am Webbrowser vertraut ei-

ner zentralen Signierinstanz. Der Signierer setzt unter jedes Applet,

das er für vertrauenswürdig hält, seine digitale Unterschrift. Der Si-

gnaturalgorithmus verhindert, dass der Code nach Ausstellung der

Unterschrift unerkannt geändert werden kann. Wenn die Signierin-

stanz ihre Aufgabe ordnungsgemäß erledigt, ist dies ein sicherer An-

satz, um Klienten vor bösartigen Servern zu schützen.

2.1.2

Sicherheitskonzepte zum Schutz von Servern

Principle-basierende Sicherheitsmechanismen:

Für serverseitige Appli-

kationen stellt sich das Sicherheitsproblem aber völlig anders. Der

Code läuft meist auf dem gleichen Rechner, von dem aus er auch ge-

laden wird. Solchem Code kann a priori vertraut werden. Vielmehr

besteht bei derartigen Systemen eine Gefährdung in der Gegenrich-

tung: bösartige Klienten attackieren den Server. Ein Codebase- oder

signaturbasierender Sicherheitsmechanismus kann davor nicht schüt-

zen. Vielmehr muss der Klient in den Mittelpunkt der Sicherheits-

betrachtung gezogen werden. Ein eindeutig authentifizierter Klient

wird in diesem Kontext auch als Principle bezeichnet. Es wird folg-

lich ein Principle-basierender Kontrollmechanismus benötigt.

In dem Beispielszenario muss sich jeder Nutzer mit einer Nutzer-ID

anmelden. Darauf basierend ist der Nutzer mit ID 12345 berechtigt,

weitere Kundeninformationen einzusehen. Allen anderen Nutzern

des Systems wird dies verboten.

Rollenbasierende Sicherheitsmechanismen:

Eine Sonderform des Prin-

ciple-basierenden Sicherheitskonzepts verwendet Rollen. Die Idee

entstammt der Forschung von David Ferraiolo und Richard Kuhn

[

FK92

]. Im vorigen Absatz wurde erläutert, dass jedes Principle ein-

deutig identifiziert werden muss. Dabei muss eine Identifizierung

aus Computersicht nicht gleichbedeutend mit einer aus realweltli-

cher Sicht sein. So kann eine realweltliche Person beispielsweise ne-

ben einem normalen Account noch einen Testaccount besitzen. Für

2.1. ÜBERSICHT ÜBER DIE SICHERHEITSKONZEPTE

das System stellen beide verschiedene Nutzer dar, obwohl sich re-

alweltlich nur eine konkrete Person dahinter verbirgt. Umgekehrt

ist es oft unerwünscht, für jeden einzelnen Nutzer ein komplexes

Sicherheitssystem zu konfigurieren. Deshalb werden jedem Nutzer

nur Rollen zugeordnet, die wiederum eine bestimmte Rechtemen-

ge implizieren. Zum Ausführen einer Funktion muss der aufrufende

Nutzer eine bestimmte Rolle innehaben.

Beispielsweise existieren in dem Bankszenario die Rollen Kunde und

Kundenbetreuer. Jeder Kunde darf Basisinformationen seines eige-

nen Kontos sehen und darauf Finanztransaktionen auslösen. Alle

Inhaber der Rolle Kundenberater dürfen hingegen auch erweiterte,

bankinterne Zusatzdaten wie Kreditwürdigkeit und Statistiken eines

Kundens einsehen. Natürlich kann ein System auch vorsehen, einem

Nutzer mehrere Rollen zuzuordnen.

Zu beachten ist, dass eine Rolle wiederum ein Principle ist. Bekann-

termaßen spiegelt ein Principle einen Nutzer in der Systemsicht wi-

der. Genau das ist auch die Funktion einer Rolle nur auf einer ab-

strakteren Sichtweise.

Ergänzend wird noch erwähnt, dass rollenbasierende Sicherheitsme-

chanismen nur ein Typ der mehrschichtigen Sicherheit (Multilevel

Security) sind. Diese Klasse enthält noch einige weitere interessante

und relevante Mechanismen. Einen guten Überblick gibt [

And01

Instanzbasierende Sicherheitsmechanismen:

Das rollenbasierende Kon-

zept ist einfach und robust und deshalb für viele Anwendungen

gut geeignet. Einige Anwendungsfälle lassen sich aber mit solch ei-

ner einfachen Lösung nicht adäquat behandeln. Dazu wird das Bei-

spielszenario um einen Punkt erweitert: Kunden ist es nur gestattet,

Finanztransaktionen bis maximal 500,- Euro pro Tag auszuführen.

Diese Bedingung lässt sich ganz offensichtlich nicht mehr mit einem

Principle-basierenden oder gar einen rollenbasierenden Mechanis-

mus regulieren. Die Zugriffsentscheidung benötigt nicht nur Infor-

mationen über das Principle wie Kundennummer oder Rollenzuord-

nung, sondern auch Informationen von den zu schützenden Daten

wie ,,Summe aller Transaktionen am heutigen Tag". Mechanismen,

die auch Inhalte der zu schützenden Daten einbeziehen, werden als

instanzbasierend bezeichnet.

Diese Auflistung soll nur einen Überblick geben und erhebt keinen An-

spruch auf Vollständigkeit. Vielmehr wurden diese fünf Vertreter aus der

Menge der Sicherheitskonzepte ausgewählt, da sie für die im Rahmen

dieser Arbeit diskutierten Probleme relevant sind. Für eine umfassende-

re Übersicht sei auf [

And01

] verwiesen.

KAPITEL 2. SICHERHEITSKONZEPTE FÜR JAVA UND EJB

2.2

Sicherheitsmechanismen in Java

Die Firma Sun Microsystems erstellte Anfang der 90iger Jahre eine neue

Programmiersprache. Die später auf Java umgetaufte Sprache zeichnet

sich primär durch ihre Portabilität auf Codeebene aus. Java vermischt da-

bei Ideen der Compiler-orientierten mit denen der Interpreter-orientier-

ten Sprachen. Der Quelltext wird während des Compiliervorgangs nicht

zu Maschinencode umgesetzt, sondern nur zu einem optimierten, maschi-

nenunabhängigen Bytecode. Der erzeugte Bytecode kann danach von je-

der virtuellen Java-Maschine ausgeführt werden, das heißt, der einmal er-

zeugte Bytecode läuft ohne zusätzlichem Portierungsaufwand auf jedem

Gerät, für das eine virtuelle Maschine existiert. Solange man sich auf den

Standardfunktionsumfang beschränkt, kann der Bytecode deswegen nicht

nur auf Windows-, Apple- und Unix-Systemen ausgeführt werden, son-

dern auch auf PDAs, Java-fähigen Mobiltelefonen oder gar auf der viel

zitierten Java-fähige Mikrowelle.

Außer der Portabilität erschien den Entwicklern auch Robustheit und

Sicherheit außerordentlich bedeutsam. Die Java-Syntax basiert beispiels-

weise auf C++, wurde aber um einige besonders fehleranfällige Bestand-

teile wie Pointer oder Mehrfachvererbung bereinigt. Darüberhinaus stellt

die Programmiersprache Java viele der im Abschnitt

2.1.1

beschriebenen

Sicherheitsmechanismen bereit. Im Folgenden wird deren konkrete Um-

setzung vorgestellt.

Traditionell verfügt Java über einen Codebase-basierenden Sicherheits-

mechanismus. Das in Abbildung

2.1

dargestellte Sandboxmodell schützt

die virtuelle Maschine von Java gegen korrupten Bytecode. Dazu kann im

JDK 1.0 in sogenannten Policys definiert werden, welcher externe Code

ausgeführt werden darf. Als Entscheidungsgrundlage fungiert die Her-

kunft des Codes, die Codebase. Darüber hinaus besteht ab JDK 1.1 die

Möglichkeit, den Bytecode zu signieren und darauf basierend Sicherheits-

regeln aufzustellen.

Abbildung 2.1: Sandboxmodell des JDK 1.1

2.2. SICHERHEITSMECHANISMEN IN JAVA

2.2.1

Java 2

Als problematisch entpuppt sich, dass die Entscheidung, ob Code ausge-

führt werden darf oder nicht, für viele Anwendungen zu grob ist. Mit dem

JDK 1.2 wurde deshalb das in Abbildung

2.2

gezeigte feingranulare Sicher-

heitssystem eingeführt.

Abbildung 2.2: Sicherheitsmodell von Java 2

Ausführlich wird dieses in [

GMPS97

] erläutert. Die Sicherheitsarchitektur

von Java 2 beruht ebenfalls auf Policys. Nach wie vor führt der Security-

Manager eine Codebase-basierende oder signaturbasierende Sicherheits-

kontrolle durch. Wird diese positiv beschieden, bekommt der Code aber

nicht sofort Zugriff auf alle Ressourcen, sondern nur im Rahmen von vor-

her festgelegten Permissions.

Codebase

"http://www.secure-domain.org",

Signedby

"trustedpartner" {

permission

java.io.FilePermission " secret . txt " , "read";

permission

AWTPermission "accessEventQueue";

};

Quelltext 2.1: Java 2 Policys für Codebase-basierende Sicherheit

In Quelltext

2.1

wird zum Beispiel dem Java-Bytecode, der vom Server

secure-domain.org stammt und von trustedpartner signiert wurde, ein Le-

serecht auf secret.txt eingeräumt. Außerdem darf er die Ereigniswarte-

schlange des Oberflächen-Toolkits AWT abfragen. Es existieren darüber

hinaus weitere Permission-Klassen für fast alle Java-Standardressourcen-

zugriffe. Eigene Klassen können aus der abstrakten java.security.Permission

abgeleitet werden. Außerdem besteht mit Hilfe der abstrakten Klasse java.-

security.PermissionCollection auch die Möglichkeit, Permissions zu grup-

pieren. Zum Beispiel ist java.io.FilePermission auf diesem Wege realisiert.

Dass diese Deklarationen auch eingehalten werden, garantiert der java.-

lang.SecurityManager. Dieser wird jedes Mal befragt, wenn nicht vertrau-

enswürdiger Code versucht, sicherheitsrelevante Funktionen aufzurufen.

KAPITEL 2. SICHERHEITSKONZEPTE FÜR JAVA UND EJB

Um über einen solchen Zugriff zu entscheiden, greift der SecurityManager

auf den java.security.AccessController zurück, welcher sich wiederum den

aktuellen AccessControlContext geben lässt. Darin sind die aktuell gülti-

gen Permissions gespeichert, mit denen entschieden werden kann, ob der

Zugriff erlaubt oder verboten wird.

Hauptanwendungsgebiet des ursprünglichen Sandboxmodells waren

die Java-Applets in der Frühphase des Webs. Mit der weiteren Entwick-

lung des World Wide Webs verschwand Java aber fast vollständig aus den

Internetbrowsern. Stattdessen trat die Sprache ihren Siegeszug auf den

Servern an und etablierte sich als einer der Standards, um komplexe Ge-

schäftsanwendungen serverseitig zu entwickeln. Dafür ist das Sandbox-

modell wie in Abschnitt

2.1.2

nicht mehr adäquat. Da der Java-Bytecode

meist auf dem gleichen Server liegt, auf dem er auch ausgeführt wird, ist

die Gefährdung durch korrupten Bytecode minimal. Dafür droht nun die

Gefahr von anderer Seite: Konnten früher bösartige Server die Klienten

attackieren, gefährdeten nun bösartige Klienten die Server. Ein Codeba-

se-basierender Sicherheitsmechanismus kann für solche serverbasierende

Multi-User-Systeme nicht weiterhelfen; vielmehr muss der Sicherheitsme-

chanismus beim Klient, dem Nutzer, ansetzen.

2.2.2

Java Authentication and Authorization Service

Die Erkenntnis, zum Schutz der Server den Klienten in den Mittelpunkt

der Sicherheitsbetrachtung zu stellen, führte zur Entwicklung des Java

Authentication and Authorization Service (JAAS). Das Framework wur-

de 1999 in [

LGK

] vorgestellt und ist seit Version 1.4 beta integraler Be-

standteil des Java Developer Kits. Neben einer Schnittstelle für Authenti-

fikationsmethoden enthält das Framework auch Methoden zur Autorisie-

rung. Da Authentifizierungsmechanismen für die behandelte Problemstel-

lung dieser Arbeit nicht relevant sind, sollen sie hier auch nicht diskutiert

werden. Der Vollständigkeit halber wird auf das entsprechende Kapitel in

[

RAJ01

] verwiesen. Darin wird ein sehr umfassender Überblick, insbeson-

dere in Hinblick auf EJB, gegeben.

Der realweltliche Nutzer eines Systems wird im JAAS als sogenanntes

Subject repräsentiert. Ein Subject besteht aus einer Menge von Princip-

les und Credentials. Ein Principle stellt wiederum eine kontextabhängige

Identität dar, mit der das Subject identifiziert werden kann zum Bei-

spiel eine Mitarbeiternummer, eine Steuernummer oder einfach einen Na-

men. Jeder Dienst hat, bedingt durch ein anderes Aufgabenfeld, eine an-

dere Sicht auf die reale Welt. Deshalb kann nicht jeder Dienst realweltliche

Nutzer mit dem gleichen Merkmal identifizieren. Zieht man nun noch in

Betracht, dass ein komplexes System aus mehreren Diensten zusammen

gesetzt sein kann, wird deutlich, warum ein Subject mehrere Principles

enthalten muss.

Diese Principles bekommt das Subject bei der Authentifizierung, das

2.2. SICHERHEITSMECHANISMEN IN JAVA

Abbildung 2.3: JAAS vereint Java 2 Sicherheit und Principle

heißt der Anmeldung an das System, zugewiesen. Für ein System kann

es notwendig sein, zur Ergänzung der Principles noch weitere Authen-

tifizierungsdaten über die Zeitspanne des Anmeldeprozesses hinaus zu

speichern beispielsweise für die Authentifikation eines Teildienstes oder

zum Verschlüsseln von Emails mittels Public-Key-Verfahren. Deshalb wer-

den diese Authentifizierungsbeweise oder Credentials ebenfalls mit in dem

Subject gespeichert. Alternativ können die Credentials aber auch einfach

nur im Subject referenziert werden. Für Private-Keys in Smartcards bietet

sich dieses Verfahren beispielsweise an.

Codebase

"http://www.secure-domain.org",

Signedby

"trustedpartner",

Principal test . security . Principal "trusteduser" {

permission

java.io.FilePermission " secret . txt " , "read";

permission

AWTPermission "accessEventQueue";

};

Quelltext 2.2: JAAS Policys für Codebase-basierende Sicherheit

Die Syntax, um Policys zu beschreiben, wurde aus dem Sicherheitsmodell

von Java 2 erweitert. Basierend auf dem Beispiel aus Quelltext

2.1

kann

mit Hilfe von JAAS noch das ausführende Principle beschränkt werden.

In Quelltext

2.2

darf beispielsweise nur der Code die Datei secret.txt lesen,

der folgende drei Bedingungen erfüllt:

· von der Domain http://www.secure-domain.org geladen

· von trustedpartner unterzeichnet

· vom Principle trusteduser ausgeführt

Wie in Abschnitt

2.2.1

erläutert, greift der SecurityManager mittelbar auf

den AccessControlContext zu und erhält aus diesem die aktuell gültigen

KAPITEL 2. SICHERHEITSKONZEPTE FÜR JAVA UND EJB

Permissions. JAAS bietet darüber hinaus die Möglichkeit, dynamisch dem

AccessControlContext ein beliebiges Subject zuzuordnen. So können Funk-

tionen wahlweise mit verschiedenen Identitäten ausgeführt werden.

public class

ReadAction implements PrivilegedAction {

public

Object run () {

File file = new File("secure. txt " );

// Erzwingen einer Sicherheitsüberprüfung

(! file . exists ()) {

System.err.println("Datei secure. txt ist nicht vorhanden.");

}

Subject.doAs(trustedsubject, new ReadAction());

Quelltext 2.3: Dynamische Zuordnung eines Subject mittels doAs

Diese Funktionalität unterstützt die doAs-Methode. Quelltext

2.3

illustriert

das Vorgehen. Die Funktion ReadAction wird mit dem Subject trustedsub-

ject ausgeführt. Wie in dem Beispiel angedeutet, müssen die auszufüh-

renden Funktionen in eine Klasse verpackt werden, die das Interface Pri-

vilegedAction implementiert. Fehlt dem Subject trustedsubject beim Aufruf

der Funktion doAs das Recht, um die Datei secure.txt zu lesen, löst das

JAAS-Framework eine SecurityException aus.

2.3

Sicherheit für Enterprise Javabeans

Enterprise Javabeans sind Suns Vorschlag auf die Forderung nach einer

robusten, skalierbaren Mittelware-Architektur für komplexe Geschäftsan-

wendungen. Insbesondere im Bereich der Business-Solutions spielt Sicher-

heit eine außerordentlich große Rolle. So unterliegt auch die Sicherheits-

komponente während der Entwicklung von EJB einer stetigen Evolution.

Eine ausführliche Behandlung der Konzepte von EJB würden den Rahmen

der vorliegenden Arbeit sprengen. Es sei auf das [

RAJ01

] verwiesen.

2.3.1

Historischer Abriss

In der EJB 1.0-Spezifikation [

MH98

] empfiehlt Sun den Einsatz von Identi-

tätsobjekten, wie in Abbildung

2.4

dargestellt. Diese reflektieren bestimm-

te Anwender und Gruppen und werden mit einzelnen Methoden assozi-

iert. Dies funktioniert zwar, ist aber unflexibel. Der EJB-Entwickler kann

die Identitätsobjekte noch nicht schreiben, da dies konkrete Kenntnisse

des ACL-Repositorys der Zielumgebung voraussetzt. Der Installateur muss

nun diese Aufgabe übernehmen, was aber daran gebunden ist, dass er

2.3. SICHERHEIT FÜR ENTERPRISE JAVABEANS

über konkrete Kenntnisse der Bean-Methoden verfügt. Die von EJB pro-

pagierte Rollenteilung wird damit verwischt.

Abbildung 2.4: Identitätsobjekte in EJB 1.0

Dies ist ein wenig befriedigender Ansatz, der deshalb mit der EJB 1.1

Spezifikation [

MH99

] abgeschafft wurde. Es wurden logische Rollen ein-

geführt und damit eine klarere Trennung zwischen EJB-Entwickler und

Installateur geschaffen. Damit verschiebt sich der Fokus von den Metho-

den auf die Rollen. Die Zuordnung muss ab EJB 1.1 auch nicht mehr mit-

tels Identitätsobjekten programmiert werden, sondern kann jetzt in XML-

Deskriptoren beschrieben werden. Da sich das Vorgehen kaum vom EJB

2.0-Standard unterscheidet, wird in Abschnitt

2.3.3

nur der EJB 2.0-Weg

ausführlich demonstriert. Für eine detaillierte Darstellung des EJB 1.1-

Ansatzes sei auf [

Pou00

] verwiesen.

In ,,Java 2 Platform Enterprise Edition Specification, v1.4" [

Sha02

] wird

nun zwingend für alle EJB- und Web-Container die Unterstützung der

JAAS API vorgeschrieben. Dies hat aber primär Auswirkungen auf die

Authentifizierung und nur sekundär auf die hier betrachtete Autorisie-

rung. Heraushebenswert ist allenfalls, dass die Menge aller logischen Rol-

len des Subjects in EJB 2.0 als ein Principle im JAAS-Kontext behandelt

wird.

2.3.2

Programmierorientierte und deklarative Sicherheit

Traditionell bauen Softwareentwickler auf sicherheitsbewußte Anwendun-

gen. Das Programm entscheidet eigenständig, ob es dem Nutzer die Aus-

führung bestimmter Funktionen erlaubt oder verwehrt. Ohne Unterstüt-

zung einer Plattform mit Sicherheitskomponenten gibt es auch keine Al-

ternative zu diesem sogenannten programmierorientierten Sicherheitskon-

zept.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2003
ISBN (eBook): 9783832469634
ISBN (Paperback): 9783838669632
Dateigröße: 1.8 MB
Sprache: Deutsch
Institution / Hochschule: Technische Universität Dresden – Informatik
Erscheinungsdatum: 2014 (April)
Note: 1,7
Schlagworte: jboss enterprise javabeans jaas security middleware

Autor

Ronny Röller (Autor:in)

Instanzbasierte Zugriffsmechanismen für EJB-basierte Datenbankanwendungen

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Ronny Röller (Autor:in)