Authentisierung und Autorisierung in klassischen JavaEE-Containern und deren leichtgewichtigen Alternativen

Transkript

1 Fakultät für Informatik und Mathematik Master Wirtschaftsinformatik Authentisierung und Autorisierung in klassischen JavaEE-Containern und deren leichtgewichtigen Alternativen Studienarbeit im Fachwissenschaftlichen Wahlpichtfach Komponentenorientierte Softwareentwicklung Thomas Schimann ( ) Hiermit erkläre ich, Thomas Schimann, dass ich diese Arbeit selbstständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel verwendet sowie wörtliche und sinngemäÿe Zitate als solche gekennzeichnet habe. Ort, Datum Thomas Schimann

2 Inhaltsverzeichnis 2 Inhaltsverzeichnis 1 Motivation 3 2 Szenario Java Enterprise Architekturen Beispielszenario Webshop Bewertungskriterien Sicherheit in der Java Enterprise Edition Architektur Authentisierung HTTP Basic/Digest Authentisierung HTTPS Client Authentisierung Formular-basierte Authentisierung Java Authentication and Authorization Service Autorisierung Deklarative Autorisierung Autorisierung mit Annotations Programmatische Autorisierung Zusammenfassung Sicherheit mit Spring Security Architektur Authentisierung HTTP Basic/Digest Authentisierung X.509 Authentisierung Formular-basierte Authentisierung Weitere Funktionen Autorisierung Web Request Security Service Layer Security Domain Object Instance Security Zusammenfassung Fazit 27 Listingverzeichnis 28 Abbildungsverzeichnis 29 Literaturverzeichnis 30

3 1 Motivation 3 1 Motivation Informations- und Datensicherheit sind entscheidende vorausgesetzte Kriterien für den Einsatz von Softwaresystemen, die unternehmenskritische Informationen und Dienste bereitstellen. Die meistgenannten Ziele der Informationssicherheit sind dabei Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität (vgl. [Eckert 2008, S. 6]). Vertraulichkeit bedeutet, dass nur befugte Anwender Zugri auf geschützte Informationen und Dienste erhalten und unbefugte Benutzer diese nicht zu Gesicht bekommen. Entsprechend der Vertraulichkeit wird durch die Integrität eines Softwaresystems sichergestellt, dass nur befugte Anwender Informationen und Daten ändern dürfen. Das dritte Ziel, die Verfügbarkeit, beschreibt die Eigenschaft eines Systems, die Informationen befugten Benutzern unabhängig vom Einuss unbefugter Personen zur Verfügung stellen zu können. Unter Authentizität als viertem Ziel wird die Echtheit bzw. Glaubwürdigkeit eines Benutzers verstanden, die anhand einer eindeutigen Identität und charakteristischen Eigenschaften überprüfbar ist [Eckert 2008, S. 7]. Für die Umsetzung der beschriebenen Ziele und somit zur Realisierung eines sicheren Softwaresystems werden verschiedene Sicherheitsdienste in Enterprise- Applikationen benötigt, die wichtigsten darunter aus Sicht des Software-Entwicklers sind dabei die Authentisierungs- und Autorisierungsdienste auf denen der Fokus dieser Arbeit liegt. Die Authentisierung ist die Überprüfung der Identität eines Benutzers und somit eine wesentliche Funktion bzw. Voraussetzung für alle vier genannten Ziele der Informationssicherheit. Statt dem Begri Authentisierung werden in der Literatur auch oft die Begrie Authentizierung und Authentikation verwendet, die in dieser Arbeit alle als synonym betrachtet werden. Die Authentisierung eines Benutzers funktioniert üblicherweise über etwas, das man weiÿ, wie zum Beispiel eine Kombination aus einem Benutzernamen und einem Passwort oder über etwas, das man hat, wie zum Beispiel ein Zertikat, biometrische Merkmale oder Smartcards. Ein Überblick über weit verbreitete Authentisierungsverfahren ist beispielsweise in [Eckert 2008, S. 430] zu nden. Eine weitere wichtige Voraussetzung für die oben genannten Anforderungen der Informationssicherheit ist die Autorisierung von Benutzern, die auch als Zugriskontrolle bezeichnet wird. Man versteht darunter die Überprüfung von Befugnissen eines authentizierten Anwenders auf bestimmte geschützte Objekte oder Ressourcen. Üblicherweise wird dies entweder über Benutzer, Gruppen von Benutzern oder sogenannte Rollen realisiert. Ein Benutzer wird dabei einer Gruppe oder Rolle zugewiesen und eine Gruppe bzw. Rolle verfügt über bestimmte Berechtigungen. Darüber hinaus wird über die Autorisierung geprüft, welche Zugrisrechte (z.b. Lese-/Schreibrechte) ein authentizierter Benutzer auf ein geschütztes Objekt hat. Eine Zusammenfassung der wichtigsten Verfahren zur Rechteverwaltung und Zugriskontrolle ist ebenfalls in [Eckert 2008, S. 535] zu nden. Ziel dieser Arbeit ist es, die Standard-Dienste und -Funktionen für Authentisierung und Autorisierung in Unternehmensanwendungen im Java-Umfeld darzustellen und die Verfahren klassischer JavaEE-Container mit leichtgewichtigen Modellen in Spring zu vergleichen. Dabei liegt der Fokus auf der Anwendung von Authentisierung und Autorisierung in den Unternehmensanwendungen selbst, die Implementierung der Infrastruktur sowie die Vor- und Nachteile einzelner Authentisierungs- und Autorisierungsverfahren ist nicht Gegenstand dieser Arbeit. Ebenso werden weitere Sicherheitsthemen, wie zum Beispiel Transportsicherheit in verteilten Systemen, nur im Rahmen der Anwendung für die vorgestellten Dienste betrachtet. Nicht betrachtet werden allgemeine Entwurfsmuster für sichere Anwendungen oder die speziellen Angrisverfahren, vor denen Anwendungen geschützt werden sollen, wie zum Beispiel Cross-Site-Scripting oder SQL-Injection. Um die Standards und Dienste für Authentisierung und Autorisierung von klassischen JavaEE-

4 2 Szenario 4 Containern und deren leichtgewichtigen Alternativen in Spring besser erläutern und vergleichen zu können, wird in dieser Arbeit zunächst ein Beispiel-Szenario für eine Unternehmensanwendung mit entsprechenden Softwarekomponenten erläutert. Anschlieÿend wird gezeigt, wie sich diese Beispiel-Anwendung mit Mitteln der klassischen Java Enterprise Edition schützen lässt. Im darauf folgenden Kapitel werden die Sicherheitsmechanismen in ein leichtgewichtiges Komponentenmodell unter Verwendung von Spring Security übertragen. Die Arbeit schlieÿt mit einem zusammenfassenden Vergleich der beiden Technologien ab. 2 Szenario Um die Dienste für Authentisierung und Autorisierung für den Zugri auf die Web- und EJB- Komponenten in einer Java Enterprise-Umgebung erläutern zu können, wird zunächst die Architektur von Anwendungen in der Java Enterprise Edition beschrieben. Anschlieÿend wird ein anschauliches Beispiel vorgestellt, um die Anforderungen für Authentisierung und Autorisierung in den nachfolgenden Kapitel besser erläutern und vergleichen zu können. Zuletzt werden in diesem Kapitel noch weitere allgemeine Kriterien für die Bewertung der vorgestellten Lösungen beschrieben. 2.1 Java Enterprise Architekturen Bei der Java Enterprise Edition handelt es sich um die Spezikation einer Architektur für verteilte, mehrschichtige, komponentenorientierte Softwaresysteme. Produkte, die die in der Spezi- kation [Sun 2006] beschriebenen Schnittstellen und Dienste implementieren, werden auch als JavaEE-Produkte oder JavaEE-Container bezeichnet. Abbildung 1 zeigt einen Überblick über die Architektur einer JavaEE-Anwendung. Abbildung 1: Application Server und Container in der Java Enterprise Edition [Sun 2008b] Die sogenannten Container innerhalb eines Application Servers stellen eine Laufzeitumgebung für Komponenten dar und müssen diesen die in der Spezikation denierten Schnittstellen und Dienste zur Verfügung stellen, wobei diese je nach Art der Komponente unterschiedlich sein können. Die Geschäftslogik einer Anwendung wird üblicherweise in Enterprise JavaBean-Komponenten (EJB) entwickelt, die in einem EJB-Container bereitgestellt werden können. Der EJB-Container

5 2 Szenario 5 muss zum Beispiel Transaktions-, Naming-, oder Persistenzdienste zur Verfügung stellen. Neben Enterprise JavaBeans gibt es Komponenten wie Servlets, JavaServer Pages und JavaServer Faces, die auch als Web-Komponenten bezeichnet werden. Komponenten dieser Art benötigen einen Web-Container als Laufzeitumgebung. Für eine detaillierte Beschreibung der Architektur und der Dienste Java Enterprise Edition wird an dieser Stelle auf die Spezikation selbst [Sun 2006], das JavaEE-Tutorial [Sun 2008b] oder [Burke und Monson-Haefel 2006] verwiesen. Die Java Enterprise-Spezikation deniert neben den Anforderungen an JavaEE-Produkte auch verschiedene Rollen, die für die Softwareentwicklung mit der Java Enterprise Edition von Bedeutung sind. Um in den nachfolgenden Kapiteln zu zeigen, welche Rolle zu welchen Zeitpunkten und durch welche Methoden Einuss auf die Sicherheit einer Software nehmen kann, werden diese nun kurz erläutert. Die Person, die ein JavaEE-Produkt bzw. einen Container für Komponenten gemäÿ der Spezikation entwickelt, wird als Java EE Product Provider bezeichnet. Die Komponenten wie zum Beispiel EJBs, JSPs und Servlets werden von einem Application Component Provider entwickelt. Der Application Assembler fügt verschiedene Komponenten zu gröÿeren Anwendungen zusammen, die beispielsweise als Web-Archiv (WAR) oder Enterprise-Archiv (EAR) gepackt werden. Die Rolle des Deployers ist dafür zuständig, die vom Application Assembler bereitgestellten Pakete in eine ausführende Umgebung zu bringen und für diese zu kongurieren. Der System Administrator ist für der Betrieb, die Überwachung und ggf. die Konguration des JavaEE-Produkts und der JavaEE-Anwendung verantwortlich. Neben diesen Rollen deniert die Spezikation auch noch die Rollen Tool Provider und System Component Provider, die Entwicklungswerkzeuge bzw. Systemkomponenten für JavaEE-Produkte entwickeln. [Sun 2006, S. 17] 2.2 Beispielszenario Webshop Als Beispielszenario soll ein einfacher Webshop dienen. Dieser verfügt über eine grasche Benutzeroberäche, die mit Hilfe von JavaServer Pages als Web-Komponententechnologie implementiert wird. Die Nutzer des Webshops lassen sich in verschiedene Benutzergruppen untergliedern. Anonyme Benutzer sind nicht-registrierte, potentielle Kunden des Webshops. Sie dürfen den Produktkatalog betrachten und Waren zum Warenkorb hinzufügen, diesen allerdings nicht abschicken, solange sie nicht registriert sind. Kunden Die Kunden des Webshops lassen sich wiederum in mehrere Kundengruppen unterscheiden: Privatkunden sind natürliche Privatpersonen. Ihnen wird der Preis eines Produkts inkl. Mehrwertsteuer angezeigt. Geschäftskunden sind gewerbliche tätige oder juristische Personen. Wie bei Geschäftskunden üblich, wird hier der Preis exkl. Mehrwertsteuer angezeigt. Darüber hinaus unterscheiden sie die Vertragsbedingungen bei Geschäftskunden von den Bedingungen bei Privatkunden, zum Beispiel in Bezug auf Widerrufsrecht und Garantiedauer. Premiumkunden sind die umsatzstärksten Kunden des Unternehmens. Ein Privat- oder Geschäftskunde kann zusätzlich diese Rolle einnehmen und erhält so pauschal 10 Prozent Rabatt auf alle Produkte. Mitarbeiter Die Mitarbeiter des Unternehmens greifen auf den Webshop zu, um den Produktkatalog zu verwalten. Da die einzelnen Mitarbeiter nur für bestimmte Produktgruppen zuständig sind, wird hier eine Autorisierung auf einzelne Produkte benötigt.

6 2 Szenario 6 Die Benutzer- bzw. Kundendaten und der Produktkatalog des Webshops werden in einer relationalen Datenbank gespeichert. Der Aufbau des Szenarios ist in Abbildung 2 dargestellt. Abbildung 2: Aufbau des Webshop-Szenarios Nachfolgend sollen nun die Anforderungen an die Zugriskontrolle für die einzelnen Web- Komponenten erläutert werden. Produkte.jsp Diese Komponente wird verwendet, um den Produktkatalog zu durchsuchen und Produkte zum Warenkorb hinzuzufügen. Alle registrierten und nicht-registrierten Benutzer des Webshops dürfen auf diese Seite zugreifen. Bei registrierten Kunden wird gegebenenfalls der Preis angepasst, falls es sich um Geschäftskunden und/oder Premiumkunden handelt. Warenkorb.jsp zeigt einen Überblick über alle Produkte, die sich im Warenkorb benden, sowie die Summe der Einzelpreise. Alle Benutzer dürfen diese Seite betrachten, aber nur angemeldete Kunden dürfen eine Bestellung vornehmen. Prol.jsp Nur angemeldete Kunden des Unternehmens können ihre Prolinformationen, wie zum Beispiel Anschrift und Bankverbindung, bearbeiten. Um diese Anforderungen umzusetzen, wird ein Authentisierungsdienst sowie eine Autorisierung für Webserver-Anfragen benötigt. Diese Sicherheitsanforderung wird im folgenden als Web- Request-Security bezeichnet. Die Geschäftslogik des Webshops ist, wie in der JavaEE-Architektur üblich, in Enterprise JavaBeans gekapselt um Plattformdienste wie zum Beispiel Transaktions- und Remoting-Dienste nutzen zu können. Eine Enterprise JavaBean ist dann als Dienstanbieter zu betrachten, dessen Dienste von Web-Komponenten genutzt werden. Der Shop-Dienst ist über das folgende Interface deniert: public interface IShop { /* * Listet alle Produkte auf. */ public List < Product > getproducts () ; /*

7 3 Sicherheit in der Java Enterprise Edition 7 } * Aktualisiert den Produktkatalog */ public void setproducts ( List < Product > products ); /* * Berechnet den Preis eines Produkts */ public Double getprice ( Product product ); /* * Gibt eine Bestellung auf */ public void order ( Order order ); Listing 1: Dienst-Schnittstelle IShop Die in Listing 1 sichtbaren Methoden der Business-Schicht haben ebenfalls unterschiedliche Anforderungen an Authentisierung und Autorisierung. Dementsprechend werden auch für die EJB- Komponente Authentisierungs- und Autorisierungsdienste benötigt. 2.3 Bewertungskriterien Die im vorigen Abschnitt beschriebenen Sicherheitsanforderungen für das Beispielszenario stellen eine Grundlage für die Bewertung der Authentisierungs- und Autorisierungsdienste in den beiden Architekturen dar. Darüber hinaus sind weitere Kriterien der Sicherheitsimplementierungen für eine objektive Bewertung und einen Vergleich der Lösung notwendig. Ein wichtiges Kriterium ist die Portabilität der Webshop-Anwendung. Die Anwendung sollte auf beliebigen JavaEE- Containern/Servern lauähig sein, und damit das sogenannte Write Once, Run Anywhere- Prinzip unterstützen. Hersteller-spezische Abhängigkeiten müssen vermieden werden, da sie in den meisten Fällen eine Portierung auf ein anderes Produkt erheblich erschweren. Ein weiterer Aspekt bei der Bewertung ist die Trennung von Zuständigkeiten (Separation of Concerns). Das bedeutet, dass der Code der eigentlichen Webshop-Anwendung frei von Authentisierungs- und Autorisierungslogik sein sollte. Des Weiteren sollte eine exible Sicherheitslösung Möglichkeiten bieten, über Schnittstellen die vorhandene Logik zu erweitern bzw. zu ersetzen. 3 Sicherheit in der Java Enterprise Edition Die Anforderungen an die Sicherheitsdienste in der Java Enterprise Edition sind in der Spezikation von JavaEE dokumentiert [Sun 2006, S. 25]. Die Ziele der Sicherheitsarchitektur von JavaEE sind laut Spezikation unter anderem Portabilität, Transparenz, Isolation, Erweiterbarkeit, Flexibilität und Abstraktion. Unter Portabilität wird dabei die Eigenschaft von JavaEE-Anwendungen verstanden, in allen JavaEE-Implementierungen lauähig zu sein. Man spricht in diesem Zusammenhang auch vom Write Once, Run Anywhere- Konzept. Das Ziel Isolation bedeutet, dass das JavaEE-Produkt fähig ist, die Authentisierung und Zugangskontrolle gemäÿ den Vorgaben des Deployers und des System Administrators vorzunehmen. Das bedeutet, dass die Authentisierung und Zuordnung von Benutzern zu Rollen nicht in der JavaEE-Anwendung selbst umgesetzt werden, sondern in der jeweiligen Implementierung der JavaEE-Spezikation, also in der Regel in einem Application Server. Erweiterbar im Sinne der JavaEE-Spezikation bedeutet, dass Enterprise-Anwendungen, die sich auf die in der Spezikation beschriebenen Möglichkeiten für

8 3 Sicherheit in der Java Enterprise Edition 8 Authentisierung und Autorisierung beschränken, uneingeschränkt auf andere JavaEE-Produkte portierbar sind. Das Ziel der Flexibilität zielt darauf ab, dass JavaEE-Produkte keine bestimmten Sicherheitstechnologien für Authentisierung und Autorisierung voraussetzen, sondern nur die Implementierung von Technologien für die jeweilige Enterprise-Anwendung ermöglichen. 3.1 Architektur Die Sicherheitsarchitektur der Java Enterprise Edition lässt sich in zwei Bereiche aufteilen. Bei der deklarativen, container-verwalteten Sicherheit in J2EE wird sowohl die Authentizierung als auch die Autorisierung einer Web-Anwendung über externe Dateien, den Deployment- Deskriptoren - web.xml und ejb-jar.xml -, deniert. Authentizierung erfolgt dabei über einen Login-Dialog oder durch Zertikate, was eine sicherere Form der Authentizierung darstellt [Nimphius 2006, S. 47]. Die Container-verwaltete Sicherheit stellt die Grundlage für die Anwendung von Authentisierung und Autorisierung in Java Enterprise-Anwendungen dar. Sie deniert, wie in in einer Applikation Authentisierung aktiviert werden kann und auf welche Weise Sicherheitsbeschränkungen für Komponenten deniert werden können. Die Container-verwaltete Sicherheit in der JavaEE-Spezikation bestimmt allerdings nicht, wie ein Container die Sicherheitsentscheidungen zu treen hat, sondern überlässt dies dem Hersteller des Containers. Eine Möglichkeit, diesen zweiten Bereich der Sicherheitsarchitektur umzusetzen und die zum Beispiel im JBoss Application Server verwendet wird, ist die Integration des Java Authentication und Authorization Service (JAAS). JAAS [...] ist seit J2EE 1.4 oziell Bestandteil der J2EE-Plattform. JAAS ist Bestandteil der Java Standard Edition (J2SE) und ermöglicht Anwender-Logins gegenüber verschiedenen Authentizierungsprovidern zu prüfen. Die Entwicklung eines JAAS Login Module ist recht einfach und bietet groÿe Flexibilität in der Authentizierung [Nimphius 2006, S. 47]. Beide Bereiche der Sicherheitsarchitektur werden in den folgenden Abschnitten anhand der Authentisierungs- und Autorisierungsanforderungen genauer erläutert. 3.2 Authentisierung Für die Authentisierung eines Benutzers per Webbrowser denieren die JavaEE-Spezikation [Sun 2006] und die Servlet-Spezikation [Sun 2007] mehrere Authentisierungsmechanismen, die in den folgenden Abschnitten erläutert werden. Anschlieÿend wird gezeigt, wie eine individuelle Authentisierung mit Java Authentication und Authorization Services in einem Application Server implementiert werden kann. Bei der Authentisierung eines Benutzers für den Zugri auf Web-Ressourcen gilt immer folgender Authentisierungsprozess. Wenn ein Benutzer eine Adresse im Browser aufruft, stellt dies, wie in Abbildung 3 dargestellt, einen Request an den Webserver dar. Abbildung 3: Request an einen Webserver [Sun 2008a] Handelt es sich bei der Anfrage um eine geschützte Komponente, so ruft der Webserver den entsprechend kongurierten Authentisierungsmechanismus auf [Sun 2008a] und sendet eine Antwort

9 3 Sicherheit in der Java Enterprise Edition 9 mit entsprechender Authentisierungsauorderung an den Browser zurück (siehe Abbildung 4). Abbildung 4: Authentisierungsauforderung des Webservers [Sun 2008a] Entsprechend der kongurierten Authentisierungsart werden durch den Browser die Authentisierungsinformationen eingeholt und an den Webserver zurückgesendet, der anschlieÿend die Überprüfung der Identität vornehmen kann. Die Authentisierung im Browser kann über die folgenden Mechanismen implementiert werden, wobei die Art der Authentisierung im Deployment Descriptor des Web-Archivs (web.xml) konguriert werden kann HTTP Basic/Digest Authentisierung HTTP Basic ist das Authentisierungsverfahren der HTTP/1.0 Spezikation [Sun 2007, S. 88]. Bei diesem Verfahren wird vom Browser ein Formular für die Abfrage eines Benutzernamens und eines Passworts erzeugt und dem Anwender präsentiert (Abbildung 5). Abbildung 5: Authentisierungsdialog bei HTTP Basic [Sun 2008a] Die eingegebenen Informationen werden an den Webserver übermittelt. Die Datenübertragung erfolgt dabei nur in einer schwach verschlüsselten Form (Base64) [Duffey et al. 2001, S. 501]. Die Transportsicherheit kann aber über eine HTTPS-Verbindung zusätzlich gesichert werden. Die HTTP Digest Authentisierung erfolgt auf eine ähnliche Art und Weise, die Datenübertragung erfolgt allerdings mit dem wesentlich stärkeren MD5 Verschlüsselungsalgorithmus [Duffey et al. 2001, S. 502]. Da die HTTP Digest Authentisierung allerdings nicht so weit verbreitet ist, ist die Implementierung dieses Verfahrens laut Servlet-Spezikation optional [Sun 2007, S. 19]. Um HTTP Basic Authentisierung zu aktivieren muss der Deployment Descriptor, wie in Listing 2 dargestellt, konguriert werden. <web - app >... <login - config > <auth - method > BASIC </ auth - method ><! -- bzw. DIGEST -- > </ login - config > </web - app > Listing 2: Web.xml mit HTTP Basic/Digest Authentisierung

10 3 Sicherheit in der Java Enterprise Edition HTTPS Client Authentisierung Bei der HTTPS Client Authentisierung benötigt der Client ein Zertikat anstelle eines Passworts. Mit Hilfe dieses Zertikats kann sich der Client gegenüber dem Server authentisieren. Der Vorteil dieses Authentisierungsverfahrens ist, dass die Übertragung automatisch mit einer sicheren Verschlüsselung erfolgt. <login - config > <auth - method >CLIENT - CERT </ auth - method > </ login - config > Listing 3: Konguration der HTTPS Client Authentisierung Formular-basierte Authentisierung Neben den oben genannten Verfahren wird von den Servlet- und JavaEE-Spezikationen die Formular-basierte Authentisierung deniert ([Sun 2006, S. 40] und [Sun 2007, S. 89f]). Bei diesem Verfahren erfolgt die Eingabe der Zugangsdaten direkt über ein Formular einer Website. Dadurch wird ermöglicht, dass die Authentisierung direkt in die Anwendung integriert werden kann. Damit ein Formular für dieses Verfahren funktioniert, muss es wie im folgenden Listing aufgebaut sein. < form method =" post " action =" j_security_check " > < input type =" text " name =" j_username " / ><br / > < input type =" password " name =" j_password " / ><br / > < input type =" submit " value =" Login " / ><br / > </ form > Listing 4: Formular-basierte Authentisierung - login.jsp Um die Formular-basierte Authentisierung zu aktivieren, muss das Element login-config im web.xml Deployment Descriptor entsprechend angepasst werden (Listing 5). Durch die obligatorischen Elemente form-login-page und form-error-page wird die Login-Seite und eine Login- Fehlerseite angegeben. Wenn der Benutzer bei Formular-basierter Authentisierung eine geschützte Adresse aufruft und noch nicht authentisiert ist, wird er auf die im Deployment Descriptor angegebene Seite umgeleitet. Nach erfolgreicher Authentisierung wird schlieÿlich auf die ursprünglich angeforderte Adresse zurückgeleitet. Die Login-Fehlerseite erscheint, wenn die Authentisierung nicht erfolgreich war. <login - config > <auth - method > FORM </ auth - method > <form - login - config > <form - login - page >/ login. jsp </ form - login - page > <form - error - page >/ loginerror. jsp </ form - error - page > </ form - login - config > </ login - config > Listing 5: Konguration der Formular-basierten Authentisierung Ein Nachteil der Formular-basierten Authentisierung ist, dass die Angaben des Benutzers bei Nutzung des HTTP-Protokolls im Klartext übertragen und somit von Angreifern mitgelesen werden können. Abhilfe schat in diesem Fall auch wieder eine verschlüsselte Verbindung über HTTPS. Leider fehlt bei der Formular-basierten Authentisierung eine Möglichkeit, eine Standard-Seite zu denieren, die nach erfolgreichem Login aufgerufen wird.

11 3 Sicherheit in der Java Enterprise Edition Java Authentication and Authorization Service Weder die JavaEE-Spezikation noch die Servlet-Spezikation deniert, wie die Authentisierung durch einen entsprechenden Container durchgeführt werden muss. Somit bleibt es prinzipiell dem Hersteller überlassen, entsprechende Programmierschnittstellen und Kongurationsmöglichkeiten bereitzustellen. Allerdings fordert die JavaEE-Spezikation für JavaEE-Produkte eine Unterstützung der Java Authentication und Authorization Services (JAAS) aus der Java Standard Edition [Sun 2006, S. 13f] und die Möglichkeit der Implementierung individueller Sicherheitsmechanismen [Sun 2006, S. 29f]. Bei JAAS handelt es sich um eine Java-Implementierung des Pluggable Authentication Module (PAM)-Frameworks mit dem Ziel, Sicherheitsdienste für Authentisierung und Autorisierung unabhängig von Authentisierungstechnologien zu machen. JAAS-Sicherheit ist nicht deklarativ und muss durchweg programmiert werden. Leider ist JAAS noch nicht über eine Spezikation mit dem J2EE-Container integriert, um zum Beispiel deklarative containerverwaltete Sicherheit mit der Flexibilität von JAAS zu verbinden [Nimphius 2006, S. 47]. Manche Application Server, wie zum Beispiel JBoss, ermöglichen allerdings die Nutzung von JAAS-Login- Modulen für die Container-verwaltete Sicherheit. Um eine eigene Login- und Rechteverwaltung zu entwickeln, wird eine Implementierung des Interfaces LoginModule aus dem Package javax.security.auth.spi benötigt. Ein Login-Modul wird immer bei einer notwendigen Authentisierung eines Benutzers aufgerufen. Dabei wird dem Login- Modul ein Objekt der Klasse Subject übergeben, das das aufrufende Subjekt - zum Beispiel einen Anwender oder ein Software-System - repräsentiert [Sun 2001]. Anhand der nachfolgend erläuterten Methoden soll die Implementierung und Verwendung eines LoginModules nach einer Anleitung in [Burke 2008] gezeigt werden. Die Authentisierung mit Hilfe eines Login-Moduls durchläuft mehrere Schritte, da gegebenenfalls mehrere Login-Module bei einer Authentisierung benötigt werden. void initialize(subject subject, CallbackHandler callbackhandler,...) ist die erste Methode, die bei der Authentisierung eines Objekts aufgerufen wird. Als Parameter wird dabei unter anderem das entsprechende Subject und ein CallbackHandler aufgerufen. Ein CallbackHandler wird benötigt, wenn das Login-Modul mit einer Applikation kommunizieren muss, um die Authentisierungsinformationen zu erhalten. boolean login() In der Methode login() ndet der eigentliche Authentisierungsprozess statt. Die Informationen werden vom Benutzer bzw. vom aufrufenden System über Callbacks vom CallbackHandler eingeholt (siehe Listing 6). Anschlieÿend ndet die Überprüfung der angegebenen Daten statt. public boolean login () throws LoginException { NameCallback namecallback = new NameCallback (" Username "); PasswordCallback passwordcallback = new PasswordCallback (" Password ", false ); Callback [] callbacks = new Callback []{ namecallback, passwordcallback }; try { callbackhandler. handle ( callbacks ); } username = namecallback. getname () ; char [] password = passwordcallback. getpassword () ; // Authentisierung return true ; durchführen

12 3 Sicherheit in der Java Enterprise Edition 12 } Listing 6: ShopLoginModule.login() Falls die Überprüfung der Authentisierungsinformationen fehlschlägt, muss die Methode eine LoginException zurückgeben. Falls die angegebenen Informationen später erneut benötigt werden, müssen diese gespeichert werden [Sun 2001]. boolean commit() Mit der commit()-methode wird die erfolgreiche Authentisierung abgeschlossen. Erst in dieser Methode werden also die Identitäten aus Sicht der Applikation dem Subject zugeordnet. Dafür werden konkrete Klassen der Schnittstellen Principal und Group aus den Packages java.security und java.security.acl benötigt. public boolean commit () throws LoginException { subject. getprincipals (). add ( user ); ShopGroup group = new ShopGroup (" Roles "); for ( ShopPrincipal role : roles ) { group. addmember ( role ); } subject. getprincipals (). add ( group ); return true ; } Listing 7: ShopLoginModule.commit() Wie in Listing 7 dargestellt, werden die Rollen eines Benutzers, die zunächst nichts anderes als Principals sind, in einer Gruppe mit dem Namen Roles zusammengefasst. Dies ist spezisch für den JBoss Application Server [Burke 2008]. boolean abort() Diese Methode wird ausgeführt, wenn der Authentisierungsprozess in einer login()-methode fehlgeschlagen ist. Evtl. gespeicherte Informationen, wie zum Beispiel die Zugangsdaten, müssen gelöscht werden. boolean logout() Die logout()-methode beendet eine Sitzung eines Subjects indem es alle zugeordneten Identitäten und Rollen aus dem Subject entfernt. Die Implementierung eines eigenen Login-Moduls ist also mit relativ wenig Aufwand verbunden. Wie oben aber bereits erwähnt, handelt es sich bei der Denition der Rollen um eine JBossspezische Implementierung, womit bereits die Plattformunabhängigkeit verloren geht. Darüber hinaus sind noch weitere Hersteller-spezische Anpassungen nötig. Damit JBoss ein selbstentwickeltes LoginModule verwenden kann, muss es zunächst in einer Security-Domain in der Login- Kongurationsdatei login-config.xml eingetragen werden (Listing 8). < application - policy name =" ShopSecurityDomain " > < authentication > <login - module > code =" edu. hm. fwp. auth. ShopLoginModule " flag =" required " </ login - module > </ authentication > </ application - policy > Listing 8: Konguration des ShopLoginModules in Login-cong.xml Des Weiteren muss in der entwickelten Applikation angegeben werden, welche Security-Domain verwendet werden soll. Dies geschieht im ebenfalls Hersteller-spezischen Runtime Deployment

13 3 Sicherheit in der Java Enterprise Edition 13 Descriptor - in diesem Fall die jboss-web.xml (Listing 9). Hier muss der JNDI-Name der zuvor kongurierten Security-Domain angegeben werden. <jboss - web > < security - domain > java: / jaas / ShopSecurityDomain </ security - domain > </ jboss - web > Listing 9: Konguration einer SecurityDomain - jboss-web.xml 3.3 Autorisierung Nach erfolgreicher Authentisierung eines Benutzers beim Zugri auf eine geschützte Komponente kann die Autorisierung erfolgen. Je nach Art des Authentisierungsverfahrens werden die Authentisierungsinformationen für alle folgenden Anfragen an diese Komponente erneut übertragen oder vom Server wird eine Login-Session verwaltet. Die Autorisierung der Zugrie auf Web-Komponenten wird durch den Web-Server bzw. Web-Container durchgeführt (Abbildung 6). Abbildung 6: Zugri auf eine geschützte Komponente [Sun 2008a] Nach erfolgreicher Autorisierung eines Zugris wird die generierte Antwort an den Client gesendet. Greift allerdings, wie in Abbildung 7 gezeigt, eine Web-Komponente auf eine geschützte EJB- Komponente zu, erfolgt eine weitere Autorisierung des Zugris im EJB-Container. Abbildung 7: Senden von Daten an den Web-Server [Sun 2008a] Die Spezikation der Java Enterprise Edition deniert verschiedene Möglichkeiten, Zugrisbeschränkungen für Komponenten zu denieren. Diese werden in den folgenden Abschnitten für die Verwendung in Web- und EJB-Komponenten der Shop-Szenarios genauer erläutert.

14 3 Sicherheit in der Java Enterprise Edition Deklarative Autorisierung Wie viele andere Kongurationen können auch die Zugrisbeschränkungen für Komponenten im Deployment Descriptor deniert werden. Bei der Verwendung des Deployment Descriptors müssen die vom Application Component Provider denierten Rollen im Element security-role angegeben werden (Listing 10). Im Fall des oben beschriebenen Webshops wären dies die Rollen Kunde, Geschäftskunde, Premiumkunde und Administrator. Da die Rollen sowohl für die Web- als auch die EJB-Anwendung gültig sind, werden diese im Deployment Descriptor des Enterprise Archivs deniert. < security - role > <role - name > KUNDE </ role - name > </ security - role > < security - role > <role - name > GESCHAEFTSKUNDE </ role - name > </ security - role > < security - role > <role - name > PREMIUMKUNDE </ role - name > </ security - role > < security - role > <role - name > ADMIN </ role - name > </ security - role > Listing 10: Rollendenition im Deployment Descriptor - application.xml Um die Web-Komponenten zu schützen, kann im Deployment Descriptor des Web-Archivs (web. xml) ein security-constraint angegeben werden (Listing 11). Über das Element web-resourcecollection wird eine Menge an Web-Komponenten über ein URL-Muster deniert. Hier können beispielsweise ganze Verzeichnisse oder einzelne Dateien angegeben werden. Optional kann auch eine HTTP-Methode zur Zugrisbeschränkung hinzugefügt werden, wenn zum Beispiel Formulardaten nur von bestimmten Rollen an den Server geschickt werden dürfen. Über das Element user-data-constraint können darüber hinaus Einstellungen für den Transport der Daten vorgenommen werden. < security - constraint > <web - resource - collection > <web - resource - name > shop </ web - resource - name > <url - pattern >/ warenkorb. jsp </ url - pattern > <http - method > POST </ http - method > </ web - resource - collection > <auth - constraint > <role - name > KUNDE </ role - name > </ auth - constraint > <user - data - constraint > < transport - guarantee > CONFIDENTIAL </ transport - guarantee > </ user - data - constraint > </ security - constraint > Listing 11: Zugrisbeschränkungen im Deployment Descriptor - web.xml Für die EJB-Komponenten einer Anwendung ist die Bearbeitung des EJB-Deployment Descriptors (ejb-jar.xml) notwendig. In diesem kann eine Sicherheitsbeschränkung auf EJB-Komponenten im Element method-permission angegeben werden (Listing 12). Eine method-permission muss dabei aus den obligatorischen Kind-Elementen role-name und method bestehen. Das erste dieser Elemente beinhaltet die Rollennamen, für die die Einschränkung gilt, und das zweite Element enthält entsprechend der url-pattern im Web-Deployment Descriptor ein Muster für die Methoden einer

15 3 Sicherheit in der Java Enterprise Edition 15 Enterprise Bean. Über den Ausdruck <method-name>get*</method-name> könnten beispielsweise alle Getter-Methoden einer EJB geschützt werden. <ejb - jar >... < assembly - descriptor > <method - permission > <role - name > KUNDE </ role - name > < method > <ejb - name > ShopImpl </ ejb - name > <method - name > order * </ method - name > </ method > </ method - permission > </ assembly - descriptor > </ejb - jar > Listing 12: Zugrisbeschränkungen im Deployment Descriptor - ejb-jar.xml Im oben dargestellten Listing erfolgt die Autorisierung anhand des Methodennamens. Verfügt eine Enterprise Bean aber über überladene Methoden, wird eine erweiterte Angabe der Methodendenition benötigt, wenn für die einzelnen Überladungen unterschiedliche Sicherheitsbeschränkungen gelten. Für diesen Fall kann innerhalb der Methodendenition das Element method-params, wie in Listing 13 dargestellt, hinzugefügt werden. <ejb - jar >... < assembly - descriptor > <method - permission > <role - name > KUNDE </ role - name > < method > <ejb - name > ShopImpl </ ejb - name > <method - name >* </ method - name > <method - params > <method - param > double </ method - param > </ method - params > <method - intf > Remote </ method - intf > </ method > </ method - permission > </ assembly - descriptor > </ejb - jar > Listing 13: Zugrisbeschränkungen für Überladungen im Deployment Descriptor - ejb-jar.xml Eine weitere Verfeinerung der Methodendenition stellt die Unterscheidung nach Art des Business- Interfaces dar. So kann beispielsweise die Berechtigung unterschiedlich nach Remote- bzw. Local- Interface gestaltet werden. Gültige Werte für das Element method-intf sind Remote, Home, Local, LocalHome und ServiceEndpoint. Unter bestimmten Umständen kann eine Zugrisverweigerung für alle Rollen einer Anwendung gefordert werdern, beispielsweise wenn die Anwendungen von einem Dritt-Anbieter zur Verfügung gestellt wurde und eine bestimmte Komponente oder Methode aber nicht verwendet werden soll [Burke und Monson-Haefel 2006, S. 420]. In diesem Fall bietet sich bei der deklarativen Autorisierung das Element exclude-list an. Unter diesem Element können alle EJBs und Methoden angegeben werden, auf die nicht zugegrien werden darf, durch eine Methodendenition mit method (Listing 14). <ejb - jar >...

16 3 Sicherheit in der Java Enterprise Edition 16 < assembly - descriptor > < exclude - list > < method > <ejb - name > ShopImpl </ ejb - name > <method - name >* </ method - name > </ method > </ exclude - list > </ assembly - descriptor > </ejb - jar > Listing 14: Deaktivierung von Methoden mit exclude-list Nutzt eine EJB-Komponente eine weitere Komponente, so kann es notwendig sein, diesen Aufruf unter einer anderen Identität bzw. Rolle durchzuführen. Für diesen Zweck bietet die Spezikation sogenannte RunAs-Identitäten [Sun 2006, S. 44] für Komponenten. Im Deployment Descriptor wird eine RunAs-Identität innerhalb der EJB-Denition konguriert. Alle nachfolgenden Aufrufe werden dann unter der entsprechenden Indentität durchgeführt. Soll hingegen eine Enterprise Bean immer mit der Identität des Aufrufers ausgeführt werden, wird das Element use-calleridentity anstelle eines run-as-elements angegeben. <ejb - jar version =" 3.0 " > < enterprise - beans > < session >... < security - identity > <run - as > <role - name > ADMINISTRATOR </ role - name > </run - as > <! -- <use - caller - identity / > --> </ security - identity > </ session > </ enterprise - beans > </ejb - jar > Listing 15: Run-As-Identitäten Der Vorteil der deklarativen Autorisierungsdenition ist die Unabhängigkeit der Autorisierungskonguration vom Code der Anwendung. Dadurch wird eine saubere Trennung des Applikationscodes von der Denition der Zugrisbeschränkungen ermöglicht. Die Sicherheitsinformationen können noch nach der Entwicklung einer Komponente durch Application Assembler oder Deployer hinzugefügt werden. Demnach handelt es sich bei der deklarativen Autorisierung um eine gute Lösung für Anwendungen, in denen die Sicherheitseinstellung nicht vom Application Component Provider vorgenommen werden. Ein Nachteil der deklarativen Autorisierung ist, dass unter Umständen eine Rollenunterscheidung innerhalb der Anwendung benötigt wird, zum Beispiel um den Ablauf der Geschäftslogik zu kontrollieren. Mit der Beschreibung der Zugrisbeschränkunden im Deployment Descriptor ist dies leider nicht möglich Autorisierung mit Annotations Ebenfalls einen deklarativen Ansatz verfolgt die Denition der Zugriskontolle mit Annotations. Im Gegensatz zur deklarativen Autorisierung werden hier die Angaben mit dem Code der Anwendung vermischt. Eine Annotation ist ein Sprachkonstrukt von Java, das die Angabe von Metainformationen für Typen, Variablen und Methoden erlaubt. Mit Hilfe von Annotations lassen sich die oben beschriebenen Möglichkeiten der deklarativen Autorisierung nahezu vollständig

17 3 Sicherheit in der Java Enterprise Edition 17 nachbilden. Um die Rollen einer Komponente anzugeben, kann die verwendet werden (Listing 16). Diese Annotation ist auf Web- und EJB-Komponenten anwendbar und entspricht in der Funktionalität dem Element security-role im ({ " KUNDE ", " GESCHAEFTDKUNDE ", " ADMINISTRATOR " }) public class ShopImpl implements IShop { public... } void getproducts () (" ADMINISTRATOR ") public... } void setproducts ( List < Product > products ) { Listing 16: ShopLoginModule.login() Da bei der Verwendung von Annotations die deklarative Beschreibung der Sicherheitsbeschränkungen mit dem Code der Komponente vermischt ist, werden die Informationen immer vom Application Component Provider eingetragen. Da sich aber die in der Komponente denierten Rollen von den Rollen einer Anwendung, die vom Application Assembler oder Deployer bestimmt werden, unterscheiden können, kann ein Mapping der Rollen notwendig sein. Dieses Mapping kann nur im Deployment Descriptor über das Element security-role-ref vorgenommen werden (Listing 17). Das Kind-Element role-name entspricht dem Rollennamen, der in der Komponente verwendet wird, role-link ordnet diesem eine Rolle in der Anwendung zu. <ejb - jar version =" 3.0 " > < enterprise - beans > < session > <ejb - name > ShopImpl </ ejb - name >... < security - role - ref > <role - name > KUNDE </ role - name > <role - link > CUSTOMER </ role - link > </ security - role - ref > </ session > </ enterprise - beans > </ejb - jar > Listing 17: Deaktivierung von Methoden mit exclude-list Um schlieÿlich die Methoden einer Komponente zu schützen, werden verwendet (Listing 16). Während der Zugri für eine oder mehrere Rollen explizit erlaubt wird, kann der Zugri für alle Rollen erlaubt bzw. verweigert werden. Um die Identität einer Komponente für den Aufruf anderer Komponenten zu verändern, wird die verwendet. Gegenüber der deklarativen Autorisierung hat die Autorisierung mit Annotations also einige Nachteile. Der gröÿte Nachteil ist dabei, dass die Denitionen zur Sicherheit einer Komponente fest mit dem Code der Komponente verbunden sind, obwohl dafür keine Notwendigkeit besteht. Darüber hinaus bietet die Autorisierung mit Annotations keine Möglichkeit geschützte Web-Komponenten mit URL-Mustern zu denieren.

18 3 Sicherheit in der Java Enterprise Edition Programmatische Autorisierung Eine weitere Möglichkeit der Autorisierung in der Java Enterprise Edition ist die programmatische Autorisierung. Diese wird benötigt, wenn innerhalb der Geschäftslogik, zum Beispiel für die Implementierung von Geschäftsregeln, eine Unterscheidung nach Rollen benötigt wird. Wie oben bereits beschrieben, ist dies im Shop-Szenario der Fall, wenn die Preise eines Produkts berechnet und angezeigt werden. Für Endkunden wird der Preis inkl. Mehrwertsteuer berechnet, für Geschäftskunden wird der Preis exkl MwSt angezeigt. Wie in Listing 18 dargestellt, kann die Autorisierung über die Methode iscallerinrole(string role) des EJBContexts einer Enterprise Bean (in diesem Fall SessionContext) durchgeführt werden. Darüber hinaus bietet das Objekt die Methode getcallerprincipal, die den Zugri auf das Principal-Objekt des aktuellen ({ " KUNDE ", " GESCHAEFTDKUNDE ", " ADMINISTRATOR " }) public class ShopImpl implements IShop { Resource SessionContext context public Double getprice ( Product product ) { Double result = product. getprice () ; if ( context. iscallerinrole (" GESCHAEFTSKUNDE ")) { return result ; } else { return result * 1. 19; } }... Listing 18: Programmatische Autorisierung In Web-Komponenten stehen die Methoden mit identischer Funktionalität über den HttpServletRequest zur Verfügung. Lediglich die Methodennamen unterscheiden sich, da die Methoden bei Web-Komponenten getuserprincipal bzw. isuserinrole heiÿen. Die programmatische Autorisierung ist gut geeignet, wenn die Logik einer Komponente von der Rolle des Anwenders bzw. des Aufrufers beeinusst wird. Um einen übergreifenden Schutz von Komponenten oder Methoden zu implementieren, empehlt sich die Verwendung der deklarativen Ansätze. 3.4 Zusammenfassung Die Spezikation der Java Enterprise Edition deniert zwar die Konguration der Containerverwalteten Sicherheit mit Hilfe von Deployment Descriptoren oder Annotations und die Steuerung eines Programms über programmatische Autorisierung, allerdings enthält sie keine Vorgaben in Bezug auf Implementierung der Authentisierung und Autorisierung. Die Java Authentication und Authorization Services bieten hier zwar eine Lösungsmöglichkeit, allerdings ist [JAAS] nicht ausreichend in der J2EE-Plattform eingebunden. Die J2EE-Spezikationen 1.4 und 1.5 verlangen nicht, dass JAAS in J2EE-Containern zur Implementierung von container-verwalteter Sicherheit verwendet werden kann. Gerade das ist aber notwendig, um sichere Anwendungen zu schreiben, die auf allen J2EE-Containern portierbar sind und trotzdem über ein strukturiertes Zugriskonzept verfügen [Nimphius 2006, S. 48]. Die Folge ist, dass sich zwar die Enterprise-Anwendungen

19 4 Sicherheit mit Spring Security 19 selbst ohne Aufwand portieren lassen, Authentisierungs- und Autorisierungsdienste aber gegebenenfalls einen Portierungsaufwand verursachen oder die Portierung gar nicht möglich ist. Darüber hinaus fehlen in der Java Enterprise Edition einige Funktionen, wie zum Beispiel Zugriskontrolllisten für Objekte oder eine standardisierte Schnittstelle zum Anlegen und Verwalten von Benutzerkonten [Nimphius 2006, S. 48]. 4 Sicherheit mit Spring Security Das Spring Framework ist ein leichtgewichtiger Container für die komponentenorientierte Softwareentwicklung auf Java-Basis. Durch Konzepte wie Inversion of Control (IoC) und Dependency Injection wird eine lose Kopplung von Komponenten erreicht. Dieses Kapitel soll zeigen, wie sich die oben beschriebenen Authentisierungs- und Autorisierungsmechanismen der Java Enterprise Edition mit Hilfe von Spring Security in einen leichtgewichtigen Ansatz übertragen lassen. Für dieses Kapitel wird ein Grundwissen in Dependency Injection und Aspektorientierter Programmierung mit Spring vorausgesetzt, Literatur hierzu ist zum Beispiel in [Johnson et al. 2005] zu nden. Das Spring Security Framework ist der Nachfolger des Acegi Security Systems for Spring, das seit 2003 entwickelt wurde, und hat aktuell die Versionsnummer 2.0. Spring Security ist eine auf Spring basierende Sammlung von Schnittstellen und Implementierungen für die Integration von Authentisierung und Autorisierung in leichtgewichtigen Komponentenmodellen. Seit dem letzten Release verfügt Spring Security auch über eine Kongurationsmöglichkeit mit Namensräumen, wodurch die Konguration von Spring Security in einer Anwendung erheblich vereinfacht wird. Aus diesem Grund erfolgt bei den Beispielen dieses Kapitels die Konguration nicht mit über die klassischen Springkonguration sondern über den Namensraum von Spring Security. 4.1 Architektur Authentisierung und Autorisierung sind klassische nicht-funktionale Anforderungen, die in allen Anwendungsschichten benötigt wird. Somit handelt es sich um einen cross-cutting concern, also eine anwendungsübergreifende Anforderung, für die sich die aspektorientierte Programmierung eignet. In Spring wird aspektorientierte Programmierung mit sogenannten Interceptoren realisiert. Für die Steuerung des Frameworks ist der AbstractSecurityInterceptor zuständig, der in drei Ausprägungen existiert: Der FilterSecurityInterceptor dient der Behandlung von HTTP-Anfragen. Der AspectJSecurityInterceptor und der MethodSecurityInterceptor sind AOP-basierte Implementierungen zur Behandlung von Methoden-Aufrufen, die jeweils verschiedene AOP-Implementierungen (AspectJ beziehungsweise AOP Alliance) nutzen [Ömer Gürsoy 2007, S. 16]. Ein SecurityInterceptor trit allerdings selbst keine Zugrisentscheidung, sondern delegiert diese an verschiedene Manager-Klassen [Walls und Breidenbach 2008, S. 228], die im Laufe dieses Kapitels beschrieben werden (Abbildung 8).

20 4 Sicherheit mit Spring Security 20 Abbildung 8: Delegation der Sicherheitsentscheidungen in Spring Security [Walls und Breidenbach 2008, S. 227] Alle Komponenten des Frameworks verwenden die zentralen Klassen SecurityContextHolder, SecurityContext und Authentication. Der SecurityContext stellt den aktuellen Sicherheitskontext einer Anwendung dar. Um auf den Sicherheitskontext einer Klasse zugreifen zu können, wird die statische Methode getcontext() der SecurityContextHolder-Klasse verwendet. In einem SecurityContext wird das aktuelle Authentication-Objekt hinterlegt. Dieses entspricht im Prinzip der Subject-Klasse der Java Enterprise Edition. Über die Methode getprincipal() eines Authentication-Objekts kann auf die Daten des aktuellen Benutzers zugegrien werden - üblicherweise handelt es sich dabei um ein Objekt mit dem Interface UserDetails. Dies entspricht dem Interface Principal in JavaEE. Die Berechtigungen eines Benutzers werden über GrantedAuthority -Objekte verwaltet, die den UserDetails eines Benutzers zugeordnet werden. Die folgenden Punkte erläutern diese Klassen genauer unter Betrachtung der jeweiligen Verwendung. [Spring 2007, S. 21] 4.2 Authentisierung Wie bereits erwähnt, wird die Authentisierung nicht vom dem jeweiligen SecurityInterceptor selbst durchgeführt, sondern von einem AuthenticationManager. Der AuthenticationProvider delegiert die Authentisierung wiederum an beliebig viele AuthenticationProvider, von denen es in Spring Security bereits einige Implementierungen für verschiedene Authentisierungstechnologien gibt, wie zum für Beispiel LDAP, OpenID oder JAAS. Wie in Abschnitt 2.2 beschrieben, werden die Kunden- und Benutzerdaten im Webshop-Szenario in einer relationalen Datenbank gespeichert. Um eine Datenbank als Quelle für die Authentisierungsinformationen zu verwenden, bietet Spring Security den DaoAuthenticationProvider. Dieser erhält die Daten für die Authentisierung und Rechtevergabe aus einem Data Access Object, also einem Objekt für den Zugri auf Daten. In Spring Security muss das benötigte DAO-Objekt das Interface UserDetailsService implementieren. Ein UserDetailsService lädt die UserDetails eines Benutzers anhand des Benutzernamens über die Methode loaduserbyusername(string username) aus der Datenbank. Mit Hilfe der Namespace-Konguration kann der AuthenticationProvider und der UserDetailsService auf einfache Weise konguriert werden (Listing 19). < beans:bean id =" shopuserdetailsservice " class =" edu. hm. fwp. security. ShopUserDetailsService " / >