Überblick über Java Enterprise Edition (JEE)

Core Security Patterns

Muster Mustermann

Zusammenfassung Wenn es um die Sicherheit in der Informations-

technik geht, sollte man darauf aufmerksam machen, dass nicht jeder
Softwareentwickler zugleich Experte in Fragen der Sicherheit ist. An die-
ser Stelle sollen die Sicherheitsentwurfsmuster weiterhelfen. Jedes Sicher-
heitsentwurfsmuster ist klar strukturiert und ermöglicht eine Verbindung
zu anderen Sicherheitsentwurfsmustern. Seitdem sie in der Praxis einge-
setzt werden, bewähren sie sich immer wieder bei sich wiederholenden
Aufgabenstellungen. In der vorliegenden Proseminararbeit werden acht
Java Enterprise Edition (JEE) Core Security Patterns vorgestellt. Das
sind Secure Logger, Audit Interceptor, Container Managed Security, Dy-
namic Service Management, Obfuscated Transfer Object, Secure Session
Object, Policy Delegate und Secure Service Facade. Damit die vorge-
stellten Sicherheitsentwurfsmuster besser verstanden werden, wird ein
Überblick über die JEE-Plattform verschat. Obwohl die Sicherheits-
entwurfsmuster dazu beitragen, dass Software-Systeme deutlich sicherer
werden, sind sie kein Allheilmittel. Sie alleine garantieren nicht, dass ein
System sicher ist. In Abschluss wird eine eigene Gruppierung in 4 Grup-
pen der 8 vorgestellten Entwurfsmustern erstellt und ein Ausblick für die
Zukunft der Core Security Patterns gegeben.

1 Einleitung

Sicherheit ist für viele Softwaresysteme heutzutage ein besonders wichtiges The-
ma. Angesichts der steigenden Anzahl der für Unternehmen bestimmten Dienst-
leistungen in oenen Netzwerken und auf verteilten Plattformen gewinnt die Fra-
ge über Sicherheit an Bedeutung. Aus diesem Grund muss jedes Unternehmen
die entscheidende Bedeutung der Sicherheit für Informationssysteme einsehen.
Deswegen muss es einen proaktiven und ganzheitlichen Ansatz geben, der helfen
kann, die mit den Netzwerkanwendungen verbundenen Risiken der Sicherheit im
Rahmen des Arbeitsprozesses zu reduzieren und zu verwalten. Aber es ist nicht
so einfach, die Sicherheit zu gewähren. Laut [YoWa08] deniert Devanbu dies wie
folgt: Security concerns must inform every phase of software development, from
requirements engineering to design, implementation, testing, and deployment.
Die Schwierigkeiten zur Gewährleistung der Sicherheit sind darauf zurückzu-
führen, dass nicht alle Softwareentwickler Sicherheitsspezialisten sind. Hier schaf-
fen die Entwurfsmuster groÿe Hilfe. Im Jahr 1994 haben Gamma et. al [GHJV10]
das erste Buch über Entwurfsmuster herausgegeben, in dem 23 Entwurfsmuster
beschrieben wurden. Diese vier Autoren sind unter den Entwicklern auch unter
ihrem Spitznamen Gang of Four (kurz GoF, auf Deutsch Viererbande) bekannt.
2 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Sie verhalfen mit ihrem Buch den Entwurfsmustern zum Durchbruch. Die Au-
toren denieren Entwurfsmuster wie folgt: Each pattern describes a problem
which occurs over and over again in our environment, and then describes the co-
re of the solution to that problem, in such a way that you can use this solution
a milion times over, without ever doing it the same way twice [GHJV10].
Es gibt unterschiedliche Arten von Entwurfsmustern. Sicherheitsentwurfsmuster,
die bekanntlich wiederverwendbare Lösungen für Sicherheitsprobleme darstellen,
sind eine Kategorie von Entwurfsmustern. Der Begri Sicherheitsentwurfsmuster
+
wird in [SFBHB 06] folgendermaÿen deniert: A security pattern describes a
particular recurring security problem that arises in specic contexts, and presents
a well-proven generic solution for it. The solution consists of a set of interacting
roles that can be arranged into multiple concrete design structured, as well as a
process to create one particular such structure.
Die Sicherheitsentwurfsmuster können wiederum unterschiedlichen Kategorien
eingeordnet werden. In dem Fadenmodell [Ha14] werden die Sicherheitsent-
wurfsmuster in 3 Kategorien eingeteilt: Core Security Patterns, Perimeter Se-
curity Patterns und Exterior Security Patterns. Core Security Patterns berück-
sichtigen die internen Struktur des Systems. Perimeter Security Patterns berück-
sichtigen die Authentizierung, Autorisierung und Filterung für die Zwecke der
Sicherheit, die mit den Eingangsstellen im System eng verbunden sind. Exterior
Security Patterns berücksichtigen Datenübertragung und Kommunikationspro-
tokolle. In dieser Ausarbeitung liegt aber der Schwerpunkt auf den Core Security
Patterns der Java Enterprise Edition (JEE). Bevor sie näher beleuchtet werden,
wird eine Antwort auf die Frage gegeben, wieso Sicherheitsentwurfsmuster über-
haupt wichtig sind.
Entwurfsmuster haben sich in vielen Bereichen der Softwareentwicklung als er-
folgreich erwiesen, und sie sind für die Entwicklung von sicheren Systemen beson-
ders nützlich, da sie über eine Reihe von Vorteilen verfügen. Erstens kodieren sie
das Grundlagenwissen über die Sicherheit in einer strukturierten und verständ-
lichen Weise. Zweitens werden die Entwurfsmuster so dargestellt, dass sie für die
Softwareentwickler und Systemingenieure sofort erkennbar und leicht verständ-
lich sind. Da Entwurfsmuster bereits verwendet werden, um die Organisation und
das System-Engineering-Wissen zu erfassen, ist es notwendig, die Sicherheitsent-
wurfsmuster zur Erfassung des Wissens über die Sicherheit zu verwenden, so dass
die Sicherheitssysteme besser in die Unternehmen integriert werden. Nähere In-
+
formationen darüber können in Beryy et al. [BCJM 02] gelesen werden. Der
Schwerpunkt der Sicherheit lag bisher in vielen Fällen auf der Implementierung
auf niedriger Ebene, d.h. die systemnahe Implementierung, von den Produkten.
Mit dem Einsatz der Entwurfsmuster auf allen Ebenen und in einer gemeinsamen
Struktur und Terminologie erweitert sich einerseits der Sicherheitsfokus und an-
dererseits können die höheren und unteren Ebenen integriert werden [Oask01].
Darin liegen weitere wichtige Vorteile der Sicherheitsentwurfsmuster. Anschlie-
ÿend ist zu erwähnen, dass mit den Sicherheitsentwurfsmustern Sicherheitsziele
zu realisieren sind. Wenn es um die Sicherheitsziele von JEE geht, so heiÿen sie
nach der JEE-Spezikation 1.7 [Orac14] Vertraulichkeit, Integrität, Verfügbar-
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 3

keit, Nicht-Vermehrbarkeit, Authentizität, Verlässlichkeit und Unbeobachtbar-

keit. Bevor die zur Realisierung dieser Ziele notwendigen JEE-Entwurfsmuster
ausführlich beschrieben werden, wird ein ausführlicher Überblick über die JEE-
INTEROPERABILITY 19
Plattform gegeben.

Deployment Specification has been made optional as of Java EE 7. See

2 Section EE.6.1.3,
Übersicht über“Pruned
dieJava Technologies”.
JEE-Plattform

IIOP

HTTP HTTP HTTP

JRMP
SSL IIOP SSL IIOP SSL
SOAP SOAP EJB / IIOP / SSL
JRMP JRMP
HTTP HTTP

Applet
Container

Web EJB
Container Container Database

Application
Client
Container

Java EE Platform

JRMP IIOP

SOAP HTTP
HTTP SSL

Figure EE.2-2 Java1.

Abbildung EEJava
Interoperability
EE Plattform [Orac14, S. 19]

EE.2.8 Interoperability
Die JEE-Plattform ist eine Erweiterung der Java Programmiersprache und
Java-Technologien. Sie ist eine Anwendungsarchitektur, die am besten für Un-
Many of the APIs described above provide interoperability with components that
ternehmenskontext anwendbar ist. Einen Überblick über die JEE ndet man bei
are not a part of the Java EE platform, such as external web or CORBA services.
Engel at al. [EnKT04]. Die JEE-Plattform liefert ein umfangreiches Sicherheits-
Figure EE.2-2 illustrates the interoperability facilities of the Java EE platform.
architekturmodell, das die Kernsicherheitsanforderungen einer Mehr-Schichten-
(The directions of the arrows indicate the client/server relationships of the
Anwendung erfüllt.
components.)
Da in der Ausarbeitung oft auf das Klienten-Server-Modell zugegrien wird, wird
hier dieses Konzept kurz erklärt. Das Modell beschreibt eine Möglichkeit, Auf-
gaben und Dienstleistungen innerhalb eines Netzwerkes zu verteilen. Der Klient
4 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

kann auf Wunsch einen Dienst vom Server anfordern. Der Server, der sich auf
dem gleichen oder einem beliebigen anderen Rechner im Netzwerk bendet, be-
antwortet die Anforderung.
Die klassische JEE-Anwendung ist komponentenbasiert. D.h. sie besteht aus
verschiedenen Komponenten, die von den verschiedenen Entwicklern erstellt und
dann zusammengebaut werden können. Die einzelnen JEE-Komponenten können
in drei Kategorien eingeordnet werden: die Klient-Komponente, die Web-Kom-
ponente und die Geschäfts-Komponente. Die Klient-Komponente interagiert mit
dem Benutzer, die Web-Komponenten interagiert ihrerseits über das Hypertext
Transfer Protocol (HTTP) mit dem Web-Browser und die Geschäfts-Komponen-
te interagiert mit dem Applikation-Server, um die Geschäftslogik auszuführen.
HTTP ist ein Kommunikationsprotokoll im Internet.
Die Sicherheit der JEE-Plattform basiert auf Containern und wird im Folgenden
Anhand der Abbildung 1 ausführlicher erklärt. Der Applet-Container, der Web-
Container, der Enterprise Java Beans (EJB) Container und der Anwendung-
Klienten-Container, die die JEE-Infrastruktur bilden, stellen die Dienste bereit
und verwalten sie. Auÿerdem sind die Komponenten die Elemente der Applika-
tion.
Im Folgenden sollen die vier Container, die nach der aktuellsten Java Spezika-
tion 1.7 [Orac14] erforderlich sind, ihr Ineinandergreifen und die durch Proto-
kolle nach auÿen gehende Kommunikation näher erläutert werden: Der Applet-
Container läuft auf der Benutzer-Seite einer Web-Applikation mit Java Applets
und kommuniziert über HTTP-SSL um Daten abhörsicher mit dem Web-Con-
tainer zu übertragen. Der Applikation-Klient-Container, der ebenfalls auf der
Benutzerseite eines Web-Programms ausgeführt wird, unterstützt mit Hilfe ei-
ner umfassenderen und angepassten Benutzeroberäche den Java Klient. Über
HTTP läuft die Schnittstelle vom Applikation Klient-Container nach auÿen und
über RMI/IIOP kommuniziert sie mit dem EJB-Container. In der Abkürzung
RMI/IIOP steht IIOP für Internet Inter-ORB Protokoll, eine Spezikation der
Object Management Group (OMG) und RMI steht für Remote Method Invo-
cation. Der Web-Container seinerseits wird in den Websystemen ausgeführt. Er
ist sozusagen für die Bearbeitung der HTTP-Anfragen und für die Erstellung
der Benutzeroberäche in einer Web-Applikation verantwortlich. Bei den Web-
Komponenten wird zwischen Servlets und JavaServer Pages unterschieden. Ja-
vaServer Pages ist eine Erweiterung von Servlets. Es bietet eine Unterstützung,
um XML und HTML Dateien zu erzeugen. Die erste Web-Komponente ver-
leiht dem Server mehr Eigenschaften und gewährt somit mehr Funktionalität.
Die Servlets können z.B. die Funktion der EJB-Container benutzen. Die zweite
Form der Webkomponenten, die JavaServer Pages, besteht aus HTML Codes,
oder in HTML eingebetteten Codes. JavaServer Pages haben die Aufgabe, die
Darstellung der Inhalte immer wieder exibel anzupassen. Desweiteren soll die
JavaServer Pages Kern ein Servlet generieren, das sich von JavaServer Page zu
JavaServer Page unterscheidet. Dieses Servlet kann erst danach gestartet wer-
den. Der vierte Container der Java EE-Infrastruktur ist der EJB. Er stellt den
wichtigsten Baustein der Struktur dar, denn er baut die Anwendungslogik auf,
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 5

die die Funktionen für den Klient bereitstellt. In dem Zusammenhang ist auch zu
erwähnen, dass die Standard Application Programming Interfaces(API) Dienste
im EJB-Container sind. Aus Platzgründe wird die JEE-Plattform nicht ausführ-
licher beschrieben. Mehrere Informationen liefert die aktuellste JEE Spezikati-
on 1.7 [Orac14]. Nachdem die JEE-Plattform beschrieben wurde, kann man zu
dem Hauptteil der vorliegenden Arbeit übergehen und zwar zu den JEE Core
Security Patterns.

3 JEE Core Security Patterns

In diesem Kapitel werden die folgenden 8 JEE Core Security Patterns vorge-
stellt: Secure Logger, Audit Interceptor, Container Managed Security, Dynamic
Service Management, Obfuscated Transfer Object, Secure Session Object, Policy
Delegate und Secure Service Facade. Ausführlichere Informationen über die un-
ten beschriebenen JEE Core Security-Patterns können bei Steel et al. [StNL05]
entnommen werden. Ein Überblick über diese 8 Sicherheitsentwurfsmuster ist
der Tabelle 1 zu entnehmen.
Jedes Entwurfsmuster wird im Folgenden durch die Abschnitte Beispiel, Pro-
blem, Lösung, Konsequenzen, Verwandte Entwurfsmuster und Gegenüberstel-
lung zu anderen verwandten Entwurfsmustern beschrieben. Die in dieser Prose-
+
minararbeit benutzten Abschnitte stammen aus [SFBHB 06]. In dem Abschnitt
Beispiel wird kurz ein mögliches Szenario für die Anwendung des Entwurfsmuster
vorgestellt. In dem Abschnitt Problem wird die Situation, in der das Entwurfs-
muster angewendet wird, erklärt und/oder beschreibt das Problem, das mit Hilfe
des Entwurfsmusters gelöst wird. Weiterhin werden unter dem Abschnitt Kon-
sequenzen die Vorteile bei dem Einsatz von den Entwurfsmuster aufgezählt und
die eventuellen Nachteile erwähnt. In dem Abschnitt Verwandte Entwurfsmus-
ter kann man kurz über die Entwurfsmuster lesen, die ähnliche Probleme lösen
oder zusammen mit dem jeweiligen Entwurfsmuster verwendet werden können.
In dem letzten Abschnitt werden, wie der Name schon sagt, die Entwurfsmuster
anderen verwandten Entwurfsmustern kurz gegenübergestellt bzw. es wird die
Relation, in der die Entwurfsmuster stehen, erläutert.

3.1 Secure Logger

Beispiel: Die Mitarbeiter einer Organisation haben in ihrem Intranet freien

Zugang zu Informationen, die man nicht freigeben darf. Alle durchgeführten
Aktionen von den Mitarbeiter werden in den Logdateien gespeichert. Einer die-
ser Mitarbeiter hat aber eine vertraute Information bekannt gegeben. Als dann
diese eigentlich vertraute Information allgemein bekannt wurde, konnte man im
System nicht herausnden, welcher Mitarbeiter dies gemacht hatte, weil die hin-
terlassenen Spuren in den Logdateien verwischt wurden.
Problem: Unter Logging versteht man in der Informatik generell das (auto-
matische) Speichern von Ausgaben von Prozessen oder Datenänderungen. Diese
6 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Abbildung 2. Secure Logger Klassendiagramm [StNL05, S. 578]

werden in sogenannten Logdateien hinterlegt bzw. gespeichert. Logging erlaubt

verschiedenen Applikationen, ihre Daten zu sichern, aber es sind Angrie auf
die Anwendungen möglich. Im Falle eines erfolgreichen Eindringens gibt es keine
verräterischen Anzeichen, denn der Eindringling kann die von ihm hinterlassenen
Spuren verwischen. Deswegen kann der Administrator ihn nicht verfolgen.
Lösung: Um dies zu vermeiden, stellt der Secure Logger sicher, dass die Log-
dateien nicht verändert werden können. Mit Hilfe von kryptographischen Algo-
rithmen, können die Sicherheitsspezialisten sicher stellen, dass die Logdateien
nicht verändert werden können. Um dies zu erreichen, sind mehrere komplizierte
Schritte durchzuführen. Der groÿe Vorteil von Secure Logger liegt darin, dass er
eine zentralisierte Kontrolle über das Logging ermöglicht. Somit können vertrau-
liche Informationen gegen unautorisierten Zugri zentral geschützt werden. Die
zentralisierte Kontrolle trennt die Logger-Implementierung vom Entwicklercode
und lässt diese dadurch unverändert.
Konsequenzen:
Vorteile:

 Zentralisierte Kontrolle verhindert Sicherheitslücken durch Trennung von

Logging und Sicherheit.
 Ermöglicht die frühzeitige Entdeckung unautorisierten Zugris und verhin-
dert Eindringen.
 Generische Schnittstellen ermöglichen einheitliche Benutzung, die die Sicher-
heit enthält.
 Einfachere Benutzung, weil Sicherheitsprüfungen unabhängig von Logging
durchgeführt werden können.

Nachteile:
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 7

 Kryptographische Algorithmen sind kompliziert zu berechnen und verringern

Performance.

Verwandte Entwurfsmuster: Secure Pipe: Secure Pipe sichert die Verbin-

dung zwischen Klient und Server oder zwischen mehrere Servern [StNL05].
Abstrakte Fabrik: Das Entwurfsmuster Abstrakte Fabrik bietet eine Schnitt-
stelle, um Objekte oder die Basis-Klasse, die verantwortlich für die konkrete
Information der Schnittstelle ist, zu erstellen. [GHJV10]
Universally Unique Identier(UUID): UUID bietet einen einzigartigen Identier.
Gegenüberstellung: Vorteile: Secure Pipe kann verwendet werden, um den Se-
cure Logger zu implementieren.

3.2 Audit Interceptor

Abbildung 3. Audit Interceptor Klassendiagramm [StNL05, S.626]

Beispiel: Das IT-System einer Universität verfügt über ein Auditpfad. Es

enthält viele verschiedene Informationen, wie z.B. den Zeitpunkt der Anmeldung
der Nutzer, welche Leistungen des IT-Systems ein Nutzer in Anspruch nimmt
und so weiter. Die Aktivitäten der Nutzer werden ständig mit den Informatio-
nen über ihre Rechte im System verglichen. Wenn ein Nutzer z.B. seine Rechte
überschreitet, indem er etwas herunterladen will, was ihm eigentlich untersagt
ist, dann kann man mit Hilfe des Audit Interceptor die Identität dieses Verbre-
chersherausnden und verfolgen.
Problem: Der Audit vergleicht die Anwendung der Policies mit dem Geschäfts-
standards. Der Audit speichert alle Ereignisse und gewinnt im Falle eines Angris
an Bedeutung. Der Ereignispfad muss periodisch geprüft werden, indem auf Un-
terschiede zum Standard gesucht wird. Das Auditing Rahmenwerk ist vor allem
in den frühen Entwicklungsphasen wichtig. Das Auditing Rahmenwerk muss zen-
tralisiert und von der Anwendung getrennt werden. Es muss autoritativ sein und
8 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Dienstanfragen und Antwortfehler in allen Phasen des Prüfprozesses verarbeiten

zu können.
Lösung: Der Audit Interceptor stellt sicher, dass die Applikation trotz interner
Ereignisse und Backend-Veränderungen aufrecht erhalten werden kann. Nach
einer Unterbrechung von Geschäfts-Schicht Anfragen und Antworten wird ei-
ne zentrale Prüfung durchgeführt. Dies ermöglicht die Wiederverwendung von
Code und das wiederum nimmt dem Geschäftskomponentenentwickler Backend-
Arbeit ab. Auditing-Entscheidungen sollten selbsterklärend sein. Die Reviews
sollten mehrfach durchgeführt werden, um die Standards einzuhalten. Zusätz-
lich verhindert der Audit Interceptor eine Neukompilierung der Applikation, falls
sich die Firmenstrategie in Zukunft ändern sollte.
Konsequenzen: Vorteile:

 Zentralisiert Prüfcode und macht den Quelltext wiederverwendbar.

 behandelt das Vor- und Nachbearbeiten im Falle einer Ausnahme.
 Auditing Dienste trennen Prüfung von Geschäftsdienste und erhöht so die
Entwicklungsgeschwindigkeit.
 Ermöglicht die Vorbereitung auf Änderung der Firmenstrategie durch Ver-
weis auf Prüfkatalog.

Verwandte Entwurfsmuster: Intercepting Filter: Das Intercepting Filter De-

signentwurfsmuster wird genutzt, wenn man es auf Anfrage der Applikation oder
als Antwort zu dieser Vor- und Nachbearbeiten durchführen will. [AlCM01]
Pipes and Filters: Das Pipes and Filters Entwurfsmuster kann Performance,
Skalierbarkeit und Wiederverwendbarkeit durch Verwendung von Taskelemen-
ten, die die Bearbeitung durchführen, verbessern. [Micr14]
Gegenüberstellung: Das Audit Interceptor Entwurfsmuster ist eine weniger
komplexe Variante des Intercepting Filters und dadurch besser geeignet für asyn-
chrones Schreiben. Es ist eng verwandt mit dem Pipes and Filters Entwurfsmus-
ter.
Message Interceptor Gateway: Es ist oft notwendig sowohl auf der Web-Dienste-
Schicht als auch auf der Geschäft-Schicht Auditing durchzuführen. In diesem Fall
sollte das Message Interceptor Gateway Entwurfsmuster den Audit Interceptor
durchführen.

3.3 Container Managed Security

Beispiel: Im Intranet einer Firma hat jeder Mitarbeiter freien Zugri zu den
Kontaktangaben von jedem Angestellten. Nur die Administratoren dürfen aber
diese Kontaktdaten ändern, weil sie über die sogenannten autoritativen Rechte
verfügen. Um Änderungen ausführen zu können, müssen sie sich deshalb anmel-
den.
Problem: Geschäft-Schicht-Applikationen betreuen verschiedene Nutzer über
mehrere Nutzerebene. Wenn man keine Sicherheitsentwurfsmuster benutzt, muss
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 9

Abbildung 4. Container Managed Security Klassendiagramm [StNL05, S.636]

man Sicherheitscode neuschreiben um Datenbank mit den Nutzerangaben zu ver-

walten. Jede Applikation benötigt Sicherheitswerkzeuge, um die Authentizie-
rung von Nutzern zu gewährleisten und versorgt diese mit Zugang zu relevanten
Geschäftsprodukten. Dies kann jedoch eine Hürde darstellen, da Sicherheitsbi-
bliotheken benötigt werden.
Lösung: Container Managed Security ist für die Autorisierung und Authen-
tizierung zuständig, sie sind ihrerseits die notwendige Voraussetzung für die
Deklarative Sicherheit. Durch die Verwendung von selbsterklärender Sicherheit
deniert der Entwickler Rollen und Beschreibungen (ejb-jar.xml und web.xml)
für die verschiedenen Nutzer der JEE-Ressourcen. Diese gelten jedoch nur für
die Applikation-Domain in der Domainumgebung. In der Web-Schicht ist die
Sicherheit der Applikation stärker durch Authentizierung, die den Nutzer nur
beim ersten Mal nach seinen Login-Informationen fragt, gewährleistet.
Konsequenzen: Nachteile:

 Bleibt auf dem Level der allgemeinen Informationen und kann keine fein-
granulare Sicherheit gewährleisten.
 Alle Nutzergruppen müssen vor der Entwicklung klar deniert sein, ander-
weitig muss die Applikation neu verpackt werden.
 Ist auf die Sicherheitsmechanismen des spezischen Containers beschränkt.
 JEE beinhaltet nur eine beschränkte Menge an Sicherheitsfeatures.

Verwandte Entwurfsmuster: Authentication Enforcer: Das Authentication

Enforcer Entwurfsmuster kann zum Management und zur Delegation der Au-
thentizierung und von Authentizierungsprozessen genutzt werden. [StNL05]
Secure Service Proxy: Dieses Muster ist dazu gedacht, den Zugang zu den im
Web zugänglichen JEE-Komponenten zu sichern und zu kontrollieren. [Ha14]
Interception Web Agent: Das Interception Web Agent Entwurfsmuster zeigt die
Verwendung eines Unterbrechungsmechanismus zur Gewährleistung von Sicher-
heit für Webapplikationen auf. [StNL05]
Gegenüberstellung: Authentication Enforcer verlangt die Authentizierung
10 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

eines vorher nicht authentizierten Anfragen, was einer Container Managed Se-
curity Implementierung auf der Web-Schicht einer JEE-Applikation ähnlich ist.
Der Authentication Enforcer verhält sich wie eine Geschäft-Schicht-Implemen-
tierung der Container Managed Security.

3.4 Dynamic Service Management

Abbildung 5. Dynamic Service Management Klassendiagramm [StNL05, S.646]

Beispiel: Denial of Service (kurz DoS, auf Deutsch: Dienstverweigerung)

bezeichnet in der Informationstechnik die Nichtverfügbarkeit eines Dienstes, der
eigentlich verfügbar sein sollte [RoMo01]. Wenn ein Eingri von DoS gegen Light-
weight Directory Access Protocol (LDAP) Server passiert, dann wird die Verbin-
dung zum Server abgebrochen. Infolgedessen müssen die Nutzer die Applikation
neu starten und sich neu anmelden. Der Administrator sollte dies bemerken,
den Angri genau orten und versuchen ihn zu verhindern. Er sollte weiter ein
Objekt aufrufen, so dass die Verbindung mit der Applikation wieder hergestellt
wird. [StNL05]
Problem: Sicherheit hat zwei Hauptaspekte: Beobachtung und Management.
Der erste Aspekt sucht nur Eindringlinge, während der zweite aktiv bösartiges
Eindringen verhindert. Management sollte die Möglichkeit bieten, Objekte zu
verändern und Angrie zu unterbinden, während sie passieren. Wenn mehrere
komplexe Geschäftsobjekte zur gleichen Zeit laufen, kann das Management sich
nicht auf alle gleichzeitig konzentrieren. Das kann dazu führen, dass ein DoS-
Angri gegen einen LDAP-Server und Angrien durch authentizierte Nutzer
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 11

erfolgen.
Lösung: Java Management Extension (JMX) implementiert fein-granulare Ge-
schäftsobjekte zur Laufzeit, falls dies benötigt wird.
Konsequenzen: Vorteile:

 Plain Old Java Object(POJO) stellt ein normales Objekt in der Objektori-
entierten Programmiersprache Java dar. POJOs können administriert und
ihre Attribute und Operationen können beobachtet und verwaltet werden.
 Viele Geschäftskomponente können auf gemeinsamer Basis implementiert
werden.

Verwandte Entwurfsmuster: Secure Pipe [AlCM01].

Gegenüberstellung: Das Dynamic Service Management Entwurfsmuster ver-
wendet die Secure Pipe, um die Geheimhaltung der Kommunikation zwischen
Nutzer und Managementprotokoll zu gewährleisten.

3.5 Obfuscated Transfer Object

Abbildung 6. Obfuscated Transfer Object Klassendiagramm [StNL05, S.660]

Beispiel: Eine Applikation enthält im Prol des Nutzers Informationen über

seine Kreditkarte. Wenn man für die Prole Transfer Object nutzt, bewegen
sich die Dateien durch verschiedene Geschäfts-Komponenten und stellen so ein
Sicherheitsrisiko dar. Die Information der Kreditkarten davor geschützt werden,
dass sie in eine Logdatei geleitet und missbraucht wird.
Problem: Transferobjekte ermöglichen den Verkehr von groÿen Mengen an Da-
ten zwischen verschiedenen Teilen eines Objektes innerhalb einer Applikation
und zwischen den Ebenen. Beim Transfer von Daten zwischen den Komponen-
ten erhalten die Komponenten Informationen, auf die sie keinen Zugri haben
sollten.
12 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Lösung: Obfuscated Transfer Object deniert Daten, die Schutz benötigen, und
schützt diese durch Applikation oder Implementierung. Die Produzenten und
Konsumenten vereinbaren, welche sicherheitskritischen Daten geschützt werden
müssen. Das verschleierte Transferobjekt ist nun für den Schutz des darauf fol-
genden Datentransfers verantwortlich.
Konsequenzen: Vorteile:

 Generische und sichere Möglichkeit für den Transport sicherheitskritischer

Daten .
 Zentralisierte Verschlüsselung des Codes in jedem Transferobjekt.
 Kann auswählen, welche Datenelemente geschützt werden müssen und welche
nicht.

Nachteile:

 Verringert Performanz bei groÿen Datenmengen durch Speicher und Rechen-

aufwand.

Verwandte Entwurfsmuster: Transfer Objekt: Das Transfer Objekt Ent-

wurfsmuster wird genutzt, wenn man Daten mit mehreren Attributen auf einmal
vom Klient zum Server senden will[AlCM01].
Data Transfer HashMap (Middleware Company).
Gegenüberstellung: Das Obfucstaed Transfer Objekt ist der Data Transfer
Hashmap von der Middleware Company ähnlich. Wie bei der Data Transfer
HashMap verwendet es eine Strategie, die eine darunterliegende Hashmap zum
Speichern und Wiedererhalten von Daten nutzt. Im Fall des Obfuscated Trans-
fer Objects kann diese darunterliegende HashMap durch ein Sealing Object ver-
schlüsselt sein oder in zwei Maps aufgeteilt sein, von denen eine geloggt werden
kann und die andere sicherheitsrelevante Daten enthält, auf die kein Zugri mög-
lich sein sollte.

3.6 Secure Session Object (SSO)

Beispiel: Der Nutzer meldet sich auf der Seite einer Applikation an, die sei-
ne Anmeldeangaben vertraulich behandelt. Diese Angaben werden für weitere
Anmeldungen des Nutzers in den verschiedenen Funktionen der Applikation auf-
bewahrt. Während die erste Anmeldung gesichert ist, besteht für die Daten der
weiteren Anmeldung ein Risiko. Sie können mit einem böswilligen Code oder
von einem Eindringling missbraucht werden.
Problem: Nutzerdaten sind oft tief in einer Sitzung oder über mehrere Sit-
zungen verteilt gespeichert. Cookie ist eine Textinformation, die die besuchte
Website(Server) über den Browser im Rechner des Betrachters(Klient) platziert.
Cookies und URL-Rewriting, d.h. das Umschreiben in einer besseren, lesba-
ren Form, sind eine Möglichkeit diese zusammenzufassen, dabei gibt es jedoch
Sicherheits-, Performanz- und Netzwerkauslastungsprobleme. Ein System mit
mehreren Nutzern und Applikationen ist nicht in der Lage, die Nutzerauthenti-
zierung und die Zugriskontrolle voneinander zu trennen. Stattdessen benötigt es
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 13

Abbildung 7. Secure Session Object Klassendiagramm [StNL05, S.688]

eine plattform- und ortunabhängige Sicherheitsübertragung, die die sicherheits-

kritischen Teile der Klient-Sitzung zu verteilten Applikationen transferiert. Man
benötigt eine Datenstruktur, die Autorisierung und Authentizierung vereinigt.
Ein Token sollte diesen gemeinsamen Kontext zwischen verschiedenen Applika-
tionen identizieren, um dem Nutzer eine einmalige Anmeldung zu ermöglichen.
Danach kann dieser Sicherheitskontext zu verschiedenen Adressräumen und vir-
tuellen Maschinen übermittelt werden.
Lösung: SSO abstrahiert eine Kombination aus Authentizierung und Auto-
risierung und übermittelt diese über die Grenzen der verschiedenen Ebenen.
Es schützt sicherheitsrelevante Informationen. SSO fügt Rollen, Privilegien und
Berechtigungen zusammen und transportiert diese sicher über Ebenen und asyn-
chrone Nachrichtendienste. Der Zweck besteht darin, diese einzukapseln und glo-
bale Sicherheitsinformationen eines Klienten auszutauschen.
Konsequenzen: Vorteile:

 Kontrollierter Zugri und gemeinsame Schnittstelle zu sicherheitsrelevanter

Information.
 SSO kann selbstständig Informationen verschlüsseln und diese zusammen-
kapseln.
 Minimalmögliche Wiederholung von Sicherheitsaufgaben.
 Reduzierter Netzwerk- und Speicherverbrauch - minimiert die Sitzungsin-
formation, die zwischen Klient und Server ausgetauscht werden muss. Die
Sicherheit zwischen verschiedenen Komponenten ist dadurch optimiert.
 Abstrakte herstellerspezische Implementierung möglich.

Nachteile:

 Bietet keine fein-granulierte Autorisierung, ein SSO-Anfrage wird entweder

gesendet oder nicht.

Verwandte Entwurfsmuster: Transfer Object [AlCM01].

Session Facade: Session Facade ist ein oft verwendetes Entwurfsmuster bei JEE
14 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Applikationen. Es ist als Komponente Höherer-Ebene implementiert und enthält

jegliche Interaktion zwischen Niedrig-Ebene-Komponenten. Auÿerdem bietet es
eine Schnittstelle für die Funktionen einer Applikation und entwirrt Niedrig-
Ebene-Komponenten und vereinfacht damit das Design [StNL05].
Gegenüberstellung: Die Secure Service Facade und die generische Session Fa-
cade bieten die gleichen Vorteile bei Geschäftsobjektintegration und -zusammenfassung.
Die Secure Service Facade benötigt jedoch keine EJB-Komponenten.

3.7 Policy Delegate

Abbildung 8. Policy Delegate Klassendiagramm [StNL05, S.670]

Beispiel: Die Schnittstelle von Facebook ist sehr benutzerfreundlich. Hinter

dieser Nutzerfreundlichkeit verstecken sich viele komplexe Sicherheitsdienstleis-
tungen. Wenn ein Nutzer die Einstellungen seiner Privatsphäre-Einstellungen
ändert, ist das eine ganz einfache Aufgabe für ihn. Er sieht nicht, wie seine An-
frage implementiert wurde und wie ihm dadurch seine Sicherheit gewährt wird.
Problem: Man möchte Klienten von Sicherheitsdienste trennen und die Interak-
tionen kontrollieren, indem man die Klientanfragen administriert. Man muss von
Klienten und Sicherheitsinfrastruktur abstrahieren, um die Verschränkung der
beiden zu verringern. Mit wenig Verschränkung können Klienten oder Sicher-
heitsinfrastruktur leicht durch andere Technologien ersetzt werden. Auf diese
Weise kann man das Leben der Applikation verlängern. Man möchte den Kon-
takt von Klienten und Sicherheitsinfrastruktur verringern, um potentielle Sicher-
heitslücken zu limitieren. Auÿerdem muss man die Sicherheit eines Klienten über
mehrere Verbindungen gewährleisten. Alle Geschäft-Schicht Sicherheitsfunktio-
nen müssen daher zentralisiert sein.
Lösung: Policy Delegate übermittelt Anfragen zwischen Klienten und Sicher-
heitsdienste und reduziert so die Abhängigkeiten von Klientcode und Sicher-
heitsrahmenwerk. Auÿerdem koordiniert es Geschäft-Schicht Sicherheitsdienste.
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 15

Die Abstraktion bietet eine losere Kopplung zwischen Klient und Sicherheits-
infrastruktur, die nicht einmal den Ort dieser kennen müssen. Policy Delegate
kann auÿerdem Nachrichten in verschiedene Formate und Protokolle übersetzen.
Es kann zustandslos oder mit Zustand implementiert sein.
Konsequenzen: Vorteile:

 Versteckt die Komplexität vom Klient und bietet so eine einfachere Schnitt-
stelle.
 Verbessert Performanz durch Reduktion von wiederholter Berechnung, ver-
ringert so die Antwortzeit des Systems und verbessert dessen Skalierbarkeit.
 Führt Nachrichten- und Fehler-Übersetzung aus.
 Repariert das System, wenn Fehler entstehen.

Verwandte Entwurfsmuster: Secure Base Action: Die Secure Base Action ist
ein Entwurfsmuster zum Zentralisieren und Koordinieren von Sicherheitsinfor-
+
mation in der Präsentation Schicht [BCJM 02].
Business Delegate: Das Business Delegate-Entwurfsmuster wird genutzt, um
Präsentation-Schicht und Geschäft-Schicht zu entkoppeln. Es verringert die Kom-
munikation zwischen diesen Schichten [AlCM01].
Gegenüberstellung: Eine Secure Base Action sollte einen Policy Deleagate
nutzen, um Sicherheitsdienste zu nutzen. Ein Policy Delegate ist einem Busi-
ness Delegate-Entwurfsmuster ähnlich, aber es verwendet auÿerdem eine Secure
Base Action, um die Geheimhaltung und Integrität einer Benutzersitzung zu
gewährleisten.

3.8 Secure Service Facade

Abbildung 9. Secure Service Facade Klassendiagramm [StNL05, S.679]

Beispiel: Ein Kunde gibt einen Auftrag, welcher aus vielen kleineren Aufga-
ben besteht. Die Aufgabe der Entwickler besteht darin, die Vernetzungen zwi-
16 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

schen diesen kleinen Aufgaben zu durchschauen und ein ganzheitliches benut-

zerfreundliches Produkt mit einer einfachen Schnittstelle zu liefern.
Problem: Mehr Zugangspunkte in der Geschäft-Schicht führen zu mehr po-
tentiellen Sicherheitslöchern. Jeder Zugangspunkt sollte Sicherheitsanforderun-
gen unterliegen. Diese im Nachhinein anzubringen, ist oftmals schwierig. Die
Sicherheitsimplementierungen sollten Klienten nicht bekannt sein. Man möch-
te Sicherheitsimplementierungen von individuellen Dienstkomponenten trennen
und erstere zentralisiert durchführen. Um Authentizierung, Autorisierung, Va-
lidierung und Prüfung zu gewährleisten, sollte man Sicherheitsregeln befolgen,
ohne diese den Dienstentwicklern bereitzustellen.
Lösung: Eingang in der Geschäft-Schicht, es zentralisiert komplexe Interaktio-
nen zwischen Geschäftskomponenten in einer sicheren Sitzung. Auÿerdem inte-
griert es fein-granulare, sicherheitskritische Dienstimplementierungen und bietet
eine einheitliche und sichere Schnittstelle für Klienten.
Konsequenzen: Vorteile:

 Schützt die Geschäft-Schicht durch Gewährleistung von Sicherheitsmecha-

nismen aus dem Web-Dienste-Schicht.

 Bietet dem Klient ein vereinfachtes und vereinheitlichte Schnittstelle und

nutzt lose Kopplung zwischen Klient- und Geschäftsdienste, ermöglicht da-
durch zentralisierte Vermittlung und einfachere Verwaltung.

 Entfernt Sicherheitsvalidierungen von leichtgewichtigen Dienste, nimmt ih-

nen dadurch Verantwortung ab und bietet zentralisierte Sicherheitsdienste,
dies verringert Duplizierung und Rechenzeit.

 Zentralisiert Rechteverwaltung.

 Zentralisiert Transaktionsmanagement und beinhaltet Sicherheitsattribute.

 Bietet dynamische und regelbasierte Dienstintegration sowie Sicherheit und

Nachrichtenattribute, um dynamisch die Ausführungssequenz zu bestimmen.

 Verringert den Austausch zwischen Klient und Dienste.

Verwandte Entwurfsmuster: Secure Service Proxy: Secure Service Proxy,

implementiert als Webdienst-Endpunkt, handelt als Vermittler zwischen Klient
und JEE-Komponenten mit einem Eins-zu-eins-Mapping zwischen Klient und
Session Facade [StNL05].
Session Facade: Die Session Facade verwaltet die Geschäftsobjekte und bietet
ein einheitliches und grobes Dienstzugangsschicht für die Benutzer [AlCM01].
Gegenüberstellung: Secure Service Facade beinhaltet komplexe Zusammen-
hänge zwischen den Dienste und bietet so eine zusammengefasste Schnittstelle
für den Benutzer.
Die Secure Service Facade und die generische Session Facade bieten die gleichen
Vorteile bei der Geschäftssobjekt-Integrierung und -Zusammenfassung. Die Se-
cure Service Facade benötigt jedoch keine EJB-Komponenten. Die beinhalteten
Dienste können ein beliebiges Rahmenwerk nutzen und die Fassade liefert die
passende Aufruogik dafür.
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 17

Tabelle 1. Überblick über JEE Core Security patterns

Grup- Entwurfsmuster Problem Lösung Vorteile/Nachteile

pe
1 Secure Logger Logdateien sind mani- Trennt die Logge- Frühzeitige Ent-
pulierbar. rimplementierung deckung von
von Entwicklercode. unautorisierten
Zugrien.
1 Audit Intercep- Man will Anfragen Vergleicht die Zentralisiert der
tor und Antworten von Anwendung der Prüfcode und
und für die Geschäft- Abkommen mit macht ihn wieder-
Schicht prüfen und dem Standard von verwendbar.
unterbrechen können. Enterprise, speichert
alle Ereignisse und
gewinnt im Falle
eines Angris an
Bedeutung. Der
Ereignispfad muss
periodisch geprüft
werden, um Un-
terschiede zum
Standard zu nden.
2 Container Mana- Man will die Autorisie- Rollen und Beschrei- Bleibt auf der
ged Security rung und Authentizie- bungen für die ver- Ebene der all-
rung in den JEE Ap- schiedenen Nutzer gemeinen In-
plikationen einfach und der JEE-Ressourcen formationen
standartisiert durchfüh- denieren, selbst- und kann keine
ren, ohne den Sicher- erklärendes Si- fein-granulare
heitscode neuschreiben cherheitsmodell mit Sicherheit ge-
zu müssen. statischem Mapping. währleisten.
2 Dynamic Service Wenn verschiedene Java Management Viele Geschäfts-
Management komplexe Geschäftsob- Extension (JMX) komponenten
jekte zur gleichen Zeit implementiert können auf ge-
laufen, muss sowohl fein-granulare Ge- meinsamer Basis
die Beobachtung als schäftssobjekte zur implementiert
auch das Management Laufzeit, falls dies werden.
ausgefeilt sein. Dieser benötigt wird.
Mechanismus sollte
sowohl bei einem DoS-
Angri gegen einen
LDAP-Server als auch
bei Angrien durch
authentizierte Nutzer
funktionieren.
3 Obfuscated Beim Transfer von Da- Die Transferobjekte Generische und
Transfer Object ten zwischen Kompo- sind für den Daten- sichere Mög-
nenten erhalten diese transfer selbst ver- lichkeit für den
Informationen, auf die antwortlich. Transport sicher-
sie keinen Zugri haben heitskritischer
sollten. Daten
18 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

3 Secure Session Benötigt es eine Fügt Rollen, Privi- Reduzierter

Object plattform- und or- legien und Berech- Netzwerk- und
tunabhängige Sicher- tigungen zusammen Speicherver-
heitsübertragung, die und transpor- brauch hinweg.
die sicherheitskritischen tiert diese sicher
Teile der Klient-Sitzung über Ebenen und
zu verteilten Appli- asynchrone Nach-
kationen transferiert. richtendienste.
Man benötigt weiterhin
eine Datenstruktur,
die Autorisierung und
Authentizierung verei-
nigt.
4 Policy Delegate Man möchte den Kon- Übermittelt Anfra- Versteckt Kom-
takt von Klienten und gen zwischen Klien- plexität vom
Sicherheitsinfrastruktur ten und Sicherheits- Klient und bietet
verringern, um potenti- dienste und redu- so eine einfachere
elle Sicherheitslücken zu ziert so die Abhän- Schnittstelle.
limitieren. gigkeiten von Klient-
und Sicherheitscode.
4 Secure Service Man möchte Sicher- Integriert fein-gra- Verringert den
Facade heitsimplementierungen nulare, sicherheits- Austausch zwi-
von individuellen kritische Serviceim- schen Klient und
Servicekomponenten plementierungen Dienste.
trennen und erstere und bietet eine ein-
zentralisiert durchfüh- heitliche und sichere
ren. Schnittstelle für
Klienten.
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 19

4 Verwandte Arbeiten

Die vorliegende Arbeit beschäftigt sich nur mit 8 Core Security Patterns. Ihre
Anwendung gewährleistet die Sicherheit vor solchen Gefahren, wie z.B. Leugnung
Angri und Informationspreisgabe(d.h. das Enthüllen von internen Informatio-
nen). Ein Leugnung Angri passiert, wenn eine Applikation oder ein System nicht
die richtige Kontrolle für die Benutzeraktionen hat. Wenn dieser Angri statt-
ndet, können die gespeicherten Daten auf den Protokolldateien ungültig oder
irreführend sein. In der umfangreichen Fachliteratur werden bis zu 100 verschie-
denen Security Patterns aufgelistet und verschiedene Aspekte der Sicherheitsent-
wurfsmuster behandelt, die hier nicht berücksichtigt werden konnten. Das Werk
von Steel et al. [StNL05] ist das umfangreichste mit seinen über 1000 Seiten
und das am meisten zitierte. Das Buch kann als Handbuch für Gewährleistung
von robuste End-to-End Sicherheit in den JEE Enterprise Applikationen benutzt
werden. Die 3 Autoren, die führende Spezialisten für Java Sicherheitsarchitektur
sind, geben ausführliche Information für die JEE Security pattern, Best Practices
in unterschiedliche Arten von Applikationen und etc. Alur et al. [AlCM01] hat
die Entwurfsmuster im Rahmen des Entwurfsprozess im Mittelpunkt. Haz stell-
te einen umfangreichen Sicherheitsentwurfsmuster Katalog [Ha14] zusammen,
in dem alle Entwurfsmuster anhand von verschiedenen Kriterien und Szenari-
en klassiziert werden. Diese Zusammenstellung überzeugt, wie nützlich solche
Klassikationen für die praktische Anwendung von den Entwurfsmustern sind.

5 Diskussion

In diesem Kapitel wird eine Klassikation der 8 im Rahmen der Proseminar-

arbeit ausführlich beschriebenen Core Security Patterns vorgeschlagen und auf
einige grundlegende Probleme eingegangen, die sich bei der Implementierung
von den Sicherheitsentwurfsmuster in der Praxis ergeben. Die von mir vorge-
schlagene Klassikation besteht aus 4 Gruppen je 2 Sicherheitsentwurfsmuster.
Die Kriterien für die Gruppierung sind die jeweiligen grundlegenden Funktionen
und die Methoden, die jede dieser Gruppen auszeichnen.
Zu der ersten Gruppe gehören der Secure Logger und der Audit Interceptor.
Sie ermöglichen eine zentralisierte und aktive Prüfung der reibungslosen Anwen-
dung. Beide Entwurfsmuster sind mit der Logdatei eng verbunden. Mit Hilfe
dieser Patterns kann man schnell auf Leugnung Angrie reagieren und eektiv
und ezient nach detaillierten Informationen über diese Eingrie suchen und
diese rekonstruieren. Leugnung Angri kann passieren, wenn eine Applikation
nicht angemessen die Nutzer kontrolliert und die Aktivitäten protokolliert. So
können böswillige Manipulationen durchgeführt werden oder die Identikation
von neuen Aktionen wird gefälscht. Diese Attacke kann genutzt werden, um die
Informationen über den Täter von den böswilligen Manipulationen zu verändern,
so dass falsche Informationen in die Logdatei protokolliert werden. Wenn dieser
Angri stattndet, können die Informationen, die in den Logdateien gespeichert
sind, als ungültig oder irreführend bezeichnet werden. Secure Logger hindert den
20 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

Eindringling daran, die Logdatei für die eigenen Zwecke zu ändern. Audit In-
terceptor nutzt seinerseits das Logdatei, um die momentane Funktionsweise der
Applikation mit den dafür vorgesehenen Standards zu vergleichen. Auÿerdem
bauen Secure Logger und Audit Interceptor ein standardisiertes System auf, das
dem Entwickler unwichtige Backend-Arbeit abnimmt.
Container Managed Security and Dynamic Service Management bilden die zwei-
te Gruppe. Sie sind für die Sicherheit der internen Organisation und des Mana-
gements der Applikation zuständig. Diese zwei Entwurfsmuster sind besonders
nützlich, wenn es um die Autorisierung und die Authentizierung von sehr vie-
len Nutzern geht. Sie verwalten die Reaktion gegen den Eingri, während er
andauert. Mit diesen zwei Security Patterns werden Deklarative Sicherheit und
statisches Mapping sichergestellt.
In der dritten Gruppe benden sich die zwei Entwurfsmuster Obfuscated Trans-
fer Object und Secure Session Object. Man nutzt sie, wenn die beim Transfer
von Daten mit mehreren Attributen entstandenen Probleme gelöst werden sol-
len. Das erste Entwurfsmuster dieser Gruppe gewährt das sichere Senden von
Daten zwischen den verschiedenen Teilen der Applikation, während das zweite
Entwurfsmuster die Daten zwischen die verschiedenen Sitzungen und die ver-
schiedenen Applikationen sendet. Bei dem Obfuscated Transfer Object sind die
Transferobjekte für die Sicherheit der Daten zuständig. Im Vergleich dazu sind
die Sicherheitskontexte bei Secure Session Object die Zuständigen. Zusammen-
fassend lässt sich sagen, dass die beiden Entwurfsmuster an das oben genannte
Problem unterschiedlich herangehen.
Policy Delegate und Secure Service Facade sind die zwei Entwurfsmuster der
letzten Gruppe. Sie sorgen dafür, dass die Interaktion zwischen den Klienten
und den Sicherheitsdienste reibungslos funktioniert. Für beide Entwurfsmuster
ist die Trennung von Klienten und Sicherheitsdienste charakteristisch. Das Ent-
wurfsmuster Policy Delegate vermittelt zwischen Klienten und Sicherheitsdiens-
te, indem es den Klienten daran hindert, die Komplexität der Backend Sicherheit
zu erfahren. Secure Service Facade integriert fein-granulare Anfragen und stellt
ein vereinheitlichtes Produkt vor. Die Sicherheits- und die Serviceimplementie-
rungen sind währenddessen voneinander getrennt.
Abschlieÿend soll darauf eingegangen werden, welche grundlegenden Probleme
sich bei der Implementierung von den Sicherheitsentwurfsmuster in der Praxis
ergeben, wenn man damit die vielen Lücken der IT-Sicherheit beheben will. An-
gesichts der hohen Anzahl von Sicherheitsentwurfsmustern ist es erstens sehr
schwierig, das für das jeweilige Problem geeignete Sicherheitsentwurfsmuster zu
wählen. Desweiteren soll hier erwähnt werden, dass Sicherheitsentwurfsmuster
von vielen Spezialisten im Bereich der Sicherheit als die Allheilmittel aufgefasst
werden. Es wird also übersehen, dass sie nur eine Ergänzung zu den Metho-
den und Werkzeugen der Systemsicherheit darstellen. Anstatt das Pattern an
das System anzupassen, wird das System an das Pattern angepasst. Auf diese
Weise rückt das Sicherheitsentwurfsmuster in den Mittelpunkt und man ver-
sucht alles andere daran anzupassen. Und genau darin ergibt sich aus meiner
Ansicht das gröÿte Problem. Hinzu kommt noch, dass die Implementierung von
 Überblick über Java Enterprise Edition (JEE) Core Security Patterns 21

einigen Sicherheitsentwurfsmuster das Performanz bei groÿen Datenmengen ver-

ringert, was zusätzliche Arbeit verursacht. Mehr dazu kann bei Schumacher et
+
al. [SFBHB 06] gelesen werden.

6 Zusammenfassung und zukünftige Arbeiten

In dieser Ausarbeitung wird die wichtige Rolle der Sicherheit in Softwaresys-

teme erklärt und die Schwierigkeiten für die Gewährleistung von diese werden
vorgestellt. Danach werden die Vorteile von den Einsatz von Sicherheitsentwurfs-
muster erläutert, die erforderlich sind um den Sicherheit von den Software Syste-
me zu gewährleisten. Damit man die vorgestellte 8 JEE Core Security Patterns
besser verstehen kann, wird ausführlich eine Übersicht über die JEE-Plattform
verschat. In Abschluss werden verwandte Arbeiten kurz vorgestellt und eine ei-
gene Unterteilung in 4 Gruppen der 8 vorgestellten JEE Core Security Patterns
gemacht.
Man könnte sich im Rahmen einer anderen Seminararbeit mit den JEE Perimeter
oder JEE Exterior Security Patterns auseinandersetzen. Für die JEE Perimeter
Security Patterns könnte man die folgenden beschreiben: Authentication Enfor-
cer, Authorization Enforcer, Message Interceptor Gateway, Message Inspector,
Secure Message Router. Die JEE Exterior Security patterns, die man vorstellen
kann, sind die folgenden: Secure Service Proxy,Intercepting Web Agent, Asser-
tion Builder Pattern, Single Sign-on(SSO) Delegator Pattern. Dabei kann man
dies der Vergleichbarkeit der Ergebnisse wegen nach der Methode und Herange-
hensweise der vorliegenden Arbeit machen.
Desweiteren sollten man die Entwurfsmuster praxisorientiert erforschen. Dies
kann man machen, indem man z.B. konkrete Nutzer befragt. Man kann eine
Umfrage in einigen Firmen durchführen, um festzustellen, welche Sicherheits-
entwurfsmuster eingesetzt werden, um die ganze Organisation und das Design
des eigenen Systems und die Applikation zu sichern. Es wird auch konkret danach
gefragt, welche positiven und negativen Erfahrungen mit den Entwurfsmustern
die Softwarespezialisten dieser Firmen gesammelt haben auch wie sie aus dieser
praktischen Erfahrung heraus die jeweiligen Sicherheitsentwurfsmuster verbes-
sern würden. Durch diese Feldrecherche ergibt sich nicht nur rein Rückmeldung
der Vor- und Nachteile der in der Praxis am meisten benutzten Sicherheitsent-
wurfsmustern, es können auch in Interviews verschiedene Verbesserungsideen
diskutiert werden. Es könnte auch ein Forum entstehen, in dem die Firmen aus
seiner Branche sich über Fragen und Probleme der Sicherheit austauschen könn-
ten. Dadurch wird die Qualität der Security Patterns ständig verbessert.

Literatur

AlCM01. Deepak Alur, John Crupi und Dan Malks. Core J2EE Patterns Best
Practicies and Design Strategies. Sun. 2001.
BCJM+ 02. Craig Berry, John Carnell, Matjaz Juric, Meeraj Moidoo, Nadia Nashi
und Sasha Romanosky. J2EE Design Patterns Applied. Wrox Press.
2002.
22 Fortgeschrittene Anwendungsentwicklung mit Java-Frameworks

EnKT04. Andreas Engel, Arne Koschel und Roland Tritsch. J2EE kompakt. Spek-
trum. 2004.
GHJV10. Erich Gamma, Richard Helm, Ralph Johnson und John Vlisides. De-
sign Patterns: Elements of Reusable Object-Oriented Software. Addison-
Wesley. 2010.
Ha14. Munawar Haz. Security Pattern Catalog, 07. 2014.
Micr14. Developer Network, Microsoft, 07 2014.
Oask01. Oask. Java Security 2nd ed. Addisonn-Wesley. 2001.
Orac14. Java EE Specication, Oracle Corporation, 07. 2014.
RoMo01. Mark Roth und Ron Monzillo. Securing Applications for the Java 2
Platform, Enterprise Edition (J2EE). Java One 2001 Conference, 2001.
SFBHB+ 06. Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson,
Frank Buschmann und Peter Sommerland. Security Patterns Integra-
ting Security and Systems Engineering. Wiley Series in Software Design
Patterns. 2006.
StNL05. Christopher Steel, Ramesh Nagappan und Ray Lai. Core Security Pat-
terns: Best Practices and Strategies for J2EE, Web Services and Identity
Management . Sun. 2005.
YoWa08. Nobukazu Yoshioka und Hironori Washizaki. A survey on security pat-
terns. 2008.