JavaFX. Plus CD! Java Magazin. Java Architekturen SOA Agile. Stellenmarkt 49 Spring Security mit EJB 2x 58. CD-Inhalt

Transkript

1 12.08 Plus CD! Stellenmarkt 49 mit EJB 2x 58 Deutschland 7,50 Österreich 8,60 Schweiz sfr 15,80 Java Magazin Java Architekturen SOA Agile CD-Inhalt Jax TV: Session der JAX 2008: Ted Neward: Why the Next Five Years Will Be About Languages Business-Process-Management IX Workflow Java-Frameworks: Groovy Grails Hibernate OSGi Runtimes Apache Felix Eclipse Equinox Knopflerfish OSGi JavaFX Die Zukunft der GUI-Entwicklung in Java? 16 Single-Sign-On: Central Authentication Service Rich Internet Applications CaptainCasa Enterprise Client Web Portale 2.0 Webanwendungen mit Java Portlets 45 Architektur Rich-Client-Architekturen Wie rich darf`s denn sein? 38 Performance Anti-Patterns Vorsicht bei O/R-Mappern! 64 Agile Auf die Schnelle Alle CD-Infos 3 Wie führe ich ein Requirements- Management-Tool ein? 89 D SOA Center 69 SOA Blueprint Werkzeugkasten für Architekten Sie wollen eine SOA im Unternehmen einführen. Aber welche Grundlagen sind vorab zu klären? Welche Werkzeuge werden sofort gebraucht und welche sind (zunächst) verzichtbar? Unser allgemeiner SOA Blueprint hilft, den Nutzen kommerzieller Tools sowie von Open-Source-Komponenten zu ermitteln.

2 Enterprise mit EJB 2x Neben den gängigen Möglichkeiten von (ehemals Acegi-Framework) gibt es auch die Möglichkeit, den Sicherheitskontext auf Basis von EJBs in einem Applikationskontextobjekt zu übertragen. Die Übertragung des Sicherheitskontexts wird dabei mit Spring-Bordmitteln bewältigt. von Michael Stähler it steht ein mächtiges Sicherheits-Framework zur Verfügung, das weit über die Möglichkeiten von Java EE hinausgeht. Es bietet z.b. nicht nur rollenbasierte Autorisierung, sondern mittels aspektorientierter Programmierung [1] auch daten- und objektbasierte Sicherheit. In modernen N-Tier-Architekturen steht man häufig vor dem Problem, den Sicherheitskontext zwischen den unterschiedlichen Schichten transportieren zu müssen. Dies sollte möglichst auf transparente Art und Weise passieren, um die Trennung von Businesslogik und Infrastrukturbelangen [2] zu unterstützen. Neben den bereits in vorhandenen Möglichkeiten, den Sicherheitskontext mittels RMI- oder dem Spring-eigenen HttpInvoker-Protokoll zu übertragen, soll hier ein alternativer Lösungsansatz vorgestellt werden. Aufgrund der (noch) weiten Verbreitung von EJB-2.x-Applikationen soll der Lösungsansatz anhand dieser Spezifikationsversion vorgestellt werden. Mit kann man verschiedenste Anforderungen von Sicherheitsaspekten in Enterprise-Applikationen umsetzen [3]. Im Umfeld von Enterprise Java Beans (EJBs) gibt es ebenfalls die J2EE-Security zur Absicherung von Unternehmensanwendungen. Allerdings stellt sich diese Art der Integration meist als sehr aufwändig und unflexibel heraus, da sich die Konfiguration auf unterschiedliche Deployment-Deskriptoren und proprietäre Einstellungen im Applikationsserver niederschlägt. Die damit einhergehende Vermischung von fachlich motivierter Geschäftslogik und Security-Code führt zu verunreinigtem Sourcecode und verringert zusätzlich die Möglichkeit der einfachen Testbarkeit in Unit-Tests aufgrund der direkten Abhängigkeit der Sicherheitsprüfungen zur Laufzeitumgebung. Wie der Name schon erraten lässt, basiert das Framework auf dem Spring Framework [4]. Basierend auf der leichtgewichtigen POJO- Architektur von Spring, bei der die Abhängigkeiten der unterschiedlichen Objekte mittels Dependency Injection (DI) aufgelöst werden, ist es möglich, eine nichtinvasive Integration von Sicherheitsaspekten in unterschiedlichen JavaEE- und JavaSE-Anwendungen zu erstellen. Die Konfiguration von Spring Security wird überwiegend deklarativ vorgenommen, sodass dadurch keine Änderungen am Sourcecode durchgeführt werden müssen. Damit eignet sich das Framework auch besonders gut, um in bestehende Anwendungen integriert zu werden. Mittels der in Spring 2.0 eingeführten Namespace-Konfigurationen ist es nun auch in möglich, eine vereinfachte Konfiguration (in XML) vorzunehmen. Die Konfiguration basiert auf dem Prinzip Convention over Configuration [5], mit der eine Standardkonfiguration sehr schnell erstellt werden kann und nur die vom Standard abweichenden Bedürfnisse manuell angepasst werden müssen. Das Framework unterstützt vielfältige Möglichkeiten der Authentifizierung und Autorisierung von einfacher Form- oder Basic-Authentifizierung bis hin zur NTLM-Authentifizierung in Windows-Netzwerken und Single 58 javamagazin

3 Enterprise Sign-on über den Central Authentication Service [6]. Es wird sowohl die rollen- als auch datenbasierte Autorisierung unterstützt. Die rollenbasierte Autorisierung gewährt einem Benutzer Zugriff auf eine bestimmte Operation aufgrund der Rolle, die der Benutzer inne hat. Die datenbasierte Autorisierung ermöglicht z.b. die Sicherung von Methoden aufgrund bestimmter Aufrufparameter. bietet umfangreiche Integrationsmöglichkeiten für die unterschiedlichsten Sicherheitstechnologien (LDAP, X.509 [7] usw.). Für Details sei an dieser Stelle auf die Referenzdokumentation verwiesen [8]. Problematik der Security- Integration in verteilten Anwendungen In Enterprise-Anwendungen, deren Architektur aus mehreren Applikationsschichten aufgebaut ist, stellt sich die Frage, wie man Sicherheitsaspekte über die gesamte Anwendung hinweg integrieren kann. In diesem Fall müsste der Sicherheitskontext (Benutzerdaten wie Benutzername, Passwort und Rechte) auf allen Anwendungsebenen zur Verfügung stehen. Beispielsweise könnte eine solche Anwendung aus einer Webapplikation bestehen, die in einem Servlet- Container (z.b. Tomcat) oder Applikationsserver (z.b. JBoss) betrieben wird und mit einer Datenbank verbunden ist (Abb. 1). In diesem Fall ist die komplette Anwendung auf einem Applikationsserver installiert und wird innerhalb einer JVM ausgeführt. Es handelt sich hier um keine verteilte Applikation, da eine Trennung zwischen Präsentations- und Businesslogik nur logisch, nicht jedoch physikalisch vorhanden ist. Eine Remote-Kommunikation ist nicht notwendig. Die komplette Integration von Sicherheitsaspekten beschränkt sich damit auf nur eine Anwendungsebene. Andere Anwendungsszenarien erfordern eine physikalische Trennung der Präsentationslogik von der Businesslogik. Bei Webapplikationen wird die Präsentationslogik meist in einer DMZ (Demilitarized Zone) installiert und die Businesslogik hinter einer Abb. 1: Nicht verteilte Anwendung Abb. 2: Verteilte Anwendung Firewall auf einem Applikationsserver betrieben (Abb. 2). Bei Rich Clients würde die Remote-Kommunikation beispielsweise zwischen einem Java- Swing-Client und dem Applikationsserver erfolgen. Wie in Java-EE-Anwendungen meist üblich, wird der Remote-Zugriff mittels EJBs durchgeführt. Um die Präsentationsschicht in dem Servlet- Container und die Businessschicht in dem Applikationsserver abzusichern, müssen die Benutzerinformationen mit den Authentifizierungs- und Autorisierungsdaten (Sicherheitskontext) zwischen den Anwendungsebenen ausgetauscht werden. Wünschenswert wäre also ein Mechanismus, der den Sicherheitskontext beim Aufruf der entfernten Service-Methode automatisch überträgt und der Businessebene zur Verfügung stellt. Die Übertragung dieser Informationen wäre über einen Interceptor denkbar, der den Sicherheitskontext vor dem Aufruf der eigentlichen Businessmethode hinzufügt. Leider sieht die EJB-2.x-Spezifikation den Einsatz von benutzerspezifischen Interzeptoren nicht vor, sodass man hier auf andere Technologien angewiesen ist. Die Integrationsidee Die Idee der hier vorgestellten Lösung basiert auf der Übertragung eines anwendungsbezogenen Kontextobjekts, das seinerseits das Sicherheitskontextobjekt enthält. Man könnte den Sicherheitskontext auch direkt als Parameter übergeben, allerdings bestünde dann eine direkte Abhängigkeit zum Framework. Durch die Kapselung in ein anwendungsbezogenes Kontextobjekt hält man die Schnittstelle davon unabhängig (keine Framework-Imports). Bei einem Aufruf einer entfernten Methode (Aufruf einer EJB-Methode) wird das Applikationskontextobjekt als Parameter übergeben. Dieses wiederum kann den Sicherheitskontext mit aufnehmen und wird so auf die Businessschicht übertragen. Durch diese Konvention wird sichergestellt, dass der Sicherheitskontext auch auf Businessebene verfügbar ist. Das Anwendungskontextobjekt wird nach der Authentifizierung des Benutzers erzeugt und mit dem Sicherheitskontext gefüllt. Zusätzlich könnte man hier weitere Informationen wie Spracheinstellungen (java.util.locale) oder fachlich bedingte Benutzerinformationen im Anwendungskontext hinterlegen, sofern sie nicht schon im Sicherheitskontext enthalten sind. Nach der Authentifizierung des Benutzers wird einmalig das Anwendungskontextobjekt erzeugt und mit dem Sicherheitskontext gefüllt. Der Anwendungskontext steht javamagazin

4 Enterprise Listing 1 public class HelloWorldService implements IHelloWorldService ({ ROLE_USER, ROLE_ADMIN ) public String sayhello(helloremotecontext helloremotecontext, String name) { return Hello + ROLE_ADMIN ) public String sayhellotoadmin (HelloRemoteContext helloremotecontext, String name) { return Hello Administrator + name; Listing 2 Abb. 3: Homepage von Hello- Remote dann für die Dauer der Benutzersession zur Verfügung und wird im Falle einer Webapplikation in der HTTP-Session hinterlegt. Auf Businessebene sorgt ein AOP-Interceptor für die Extraktion des Sicherheitskontexts aus dem Anwendungskontext und speichert den Sicherheitskontext mittels des SecurityContextHolder [9] im aktuellen Ausführungs-Thread java.lang.threadlocal. Ein selbst definierter Before-Advice sorgt dafür, dass vor der eigentlichen Ausführung der Businessmethode der Sicherheitskontext für die Sicherheitsüberprüfungen verfügbar ist. Aus der Webapplikation heraus wird eine Aktion ausgelöst (z.b. Formular-Submit), die den Aufruf protected HelloRemoteContext gethelloremotecontext (HttpServletRequest request) { HelloRemoteContext helloremotecontext = (HelloRemoteContext) request.getsession().getattribute( HELLO_REMOTE_CONTEXT_SESSION_KEY); if (helloremotecontext == null) { SecurityContext securitycontext = SecurityContextHolder.getContext(); helloremotecontext = new HelloRemoteContext(securityContext); this.registerhelloremotecontextinsession(helloremotecontext, request.getsession()); return helloremotecontext; einer Businessmethode zur Folge hat. Über das EJB-Remote-Interface wird eine Methode mit Übergabe des Anwendungskontexts aufgerufen. Die Geschäftslogik ist in diesem Fall als Spring-Service in normalen Java Beans (POJOs) implementiert und wird nur über dessen Java-Interface (POJI) direkt referenziert. Die Trennung von Schnittstelle und Implementierung, wie sie in Spring üblich ist, erleichtert die Testbarkeit und Austauschbarkeit der Implementierung, da sie nicht vom EJB-Container oder einer anderen Laufzeitumgebung direkt abhängig ist. Aus diesem Grund wird die Implementierung der Geschäftslogik auch nicht direkt in der EJB (Session Bean) durchgeführt. Der Service wird lediglich exportiert, d.h. eine Stateless Session Bean (EJB-Exporter) dient nur als Fassade für den Remote-Zugriff und delegiert die Methodenaufrufe an den implementierenden Service weiter. Ein AOP-Advice sorgt schließlich dafür, dass vor dem eigentlichen Methodenaufruf der Sicherheitskontext aus dem Anwendungskontext extrahiert wird und stellt diesen dem Spring-Security- Kontext auf Businessebene zur Verfügung. Die Sicherheitsüberprüfungen müssen damit nicht direkt im Fachlogikcode implementiert werden, sondern können an zentraler Stelle hinterlegt und wiederverwendet werden [2]. Mittels Java-Annotationen (@Secured) wird an der Methode angegeben, welche Sicherheitsbedingungen für die Methodenaufrufe erfüllt sein müssen, z.b. welcher Rolle der aufrufende Benutzer zugeordnet sein muss. Beispiel Hello-Remote Zur Demonstration dieses Sachverhalts soll eine kleine Hello World - Applikation dienen, die über einen HelloWorldService verschiedene sayhello-methoden zur Verfügung stellt. Diese Methoden sind über die annotiert, sodass nur Benutzer mit der dort definierten Rolle die Methode aufrufen dürfen (Listing 1). Als Deployment-Szenario soll die in Abbildung 2 dargestellte Situation gewählt werden, bei der die Webapplikation Abb. 4: Spring-Security-Login-Formular auf einem Tomcat (Version 6) als Webarchiv (WAR) und die Businessschicht mit den Spring-Services und EJBs in einem Enterprise-Archiv (EAR) auf einem entfernten JBoss-Server (Version 4.0) deployt wird. Die Webanwendung wird beispielhaft mithilfe des Struts- Frameworks implementiert. Die EJBs basieren auf der EJB-2.1-Spezifikation, können aber ebenso durch EJB 3 Session Beans ersetzt werden. Die Webanwendung ist sehr einfach gehalten und enthält lediglich zwei JSPs und eine Struts-Action-Klasse. Nach dem Deployment der WAR-Datei kann die Applikation unter dem Context-Pfad /hello-remote-web aufgerufen werden (Abb. 3). Ausgehend von der Startseite (Homepage) gibt es lediglich einen Link Secure Page, der auf eine geschützte Seite verweist. Bei einem Klick auf diesen Link wird von automatisch ein Login-Formular angezeigt, mit dem sich der Benutzer authentifizieren kann (Abb. 4). Nach erfolgreicher Anmeldung wird die geschützte Seite mit weiteren Links angezeigt (Abb. 5). Nach erfolgreichem Login wird der SecurityContext mit den Benutzerinformationen wie Benutzername, Passwort und Autorisierungsdaten (Rollen) mithilfe des SecurityContextHolder im lokalen Thread gespeichert. Er kann von nun an von der Anwendung über die statische Methode getcontext() abgerufen werden. Beim Aufruf der Businessmethode wird in der Action-Klasse zunächst der Anwendungskontext über die Methode gethelloremotecontext(httpservlet- Request request) für den Methodenaufruf angefordert und beim ersten Aufruf erzeugt (Listing 2). Der Anwendungskontext (HelloRemoteContext) wird nun bei jedem Me- 60 javamagazin

5 thodenaufruf als erster Parameter übergeben, wodurch sichergestellt wird, dass der darin enthaltene SecurityContext auf Businessebene zur Verfügung steht und wieder extrahiert werden kann. Alternativ könnte man auch einen clientseitigen Aspekt implementieren, der vor jedem Aufruf der entfernten Servicemethode den SecurityContext an den HelloRemoteContext übergibt. Das ist vor allem dann empfehlenswert, wenn sich der SecurityContext während einer Benutzersession ändert oder wenn man sichergehen will, dass der Aufrufer ein gültiges SecurityContext-Objekt im Applikationskontextobjekt übergibt. Allerdings ändert sich der SecurityContext während einer Benutzersession normalerweise nicht, sodass man hier auf den Overhead des AOP-Aspekts verzichten kann. In Listing 3 ist die clientseitige Spring-Security-Konfiguration zu sehen. An dieser Stelle wird besonders die vereinfachte Namespace-Konfiguration deutlich. Mittels des Security Namespaces kann eine Standardkonfiguration aktiviert werden (security:http autoconfig="true"), die bereits alle benötigten Klassen für eine HTTP-Security-Konfiguration einbindet. Für die Nutzung des Frameworks muss man nicht mehr genau wissen, welche Funktionalität durch welche Klasse implementiert wird. Durch die Angabe von URL-Patterns wird festgelegt, dass z.b. alle Ressourcen im secure-verzeichnis sowie alle Actions mit der Endung.do eine Authentifizierung benötigen (IS_AU- THENTICATED_REMEMBERED). Die eigentlichen Benutzerdaten werden durch die Implementierung des Interface UserDetailsService bereitgestellt. Diese enthält lediglich die Methode loaduserbyusername, die auf Basis des übergebenen Benutzernamens ein User- Details-Objekt erwartet. An dieser Stelle beziehen wir die Benutzerdaten aus der Businessschicht, sodass in der Webschicht kein direkter Zugang zur Datenbank erforderlich ist. Dadurch werden auch keine sicherheitskritischen Daten auf dem Server innerhalb der DMZ abgelegt (z.b. Benutzername und Passwort für DB-Login). Der Remote-Lookup auf die beiden Stateless Session Beans (Service Exporter) wird mittels des Spring- Abb. 5: Geschützte Seite JEE-Namespace transparent von Spring durchgeführt. Im Hintergrund führt Spring durch Nutzung des Business Delegate Patterns [11] den Remote-Lookup durch und ermöglicht dem Client die direkte Nutzung des Serviceinterface. Mit der Einbindung des Filter Proxy DelegatingFilterProxy und der Angabe des (Web-)Application- Context in der web.xml wird die deklarative, clientseitige Konfiguration abgeschlossen (Listing 4). Die serverseitige Konfiguration der Businessschicht ist in Listing 5 abgebildet. Hier kommt ebenfalls die vereinfachte Namespace-Konfiguration zum Einsatz. Eine einfache Form der Implementierung des UserDetailsService ist die Möglichkeit der direkten Auflistung von Benutzerinformationen und Rollen mittels des security:user-tags. Konkret versteckt sich dahinter die Klasse InMemoryDaoImpl, die die Benutzerinformationen in einer java.util.hashmap im Speicher hält. In der Praxis würden diese Informationen z.b. aus einer Datenbank durch eine eigene Implementierung des Interface UserDetailsService bereitgestellt werden. Für einfache Testzwecke (und für dieses Beispiel) ist diese Möglichkeit allerdings gut geeignet. Aus Gründen der Vereinfachung sind in diesem Beispiel die Spring-Bean-Definitionen in einer einzigen XML-Datei festgehalten. In der Praxis sollte man besser die fachlichen Spring Beans in einer separaten XML-Datei definieren, sodass sie von den Security-Definitionen getrennt sind. Zur Laufzeit werden dann Anzeige

6 Enterprise beide XML-Dateien zu einem gemeinsamen ApplicationContext zusammengesetzt. Durch diese Trennung kann man beim Testen der fachlichen Services die Sicherheitsüberprüfungen komplett ein- oder ausschalten. Nennenswert an dieser Stelle ist im Wesentlichen der deklarierte Before- Advice SecurityContextExtractorAspect, der mithilfe von Spring-AOP vor der eigentlichen Methodenausführung den SecurityContext aus dem HelloRemoteContext Methode extrahiert und in den SecurityContextHolder auf Businessebene speichert. Durchgeführt wird dies in der extractsecurity- Context-Methode (Listing 6). Durch die Implementierung des Interface Ordered kann die Reihenfolge der aufgerufenen Es ist möglich, die Sicherheitsprüfungen komplett ein- oder auszuschalten. Advices beeinflusst werden. Durch die Angabe von Ordered.HIGHEST_PRE- CEDENCE wird sichergestellt, dass der SecurityContextExtractorAspect mit der höchsten Priorität vor dem SecurityInterceptor von, der für die Auswertung verantwortlich ist, ausgeführt wird. Würde der SecurityContextExtractor- Aspect erst nach dem SecurityInterceptor ausgeführt werden, könnte die eigentliche Sicherheitsüberprüfung aufgrund des fehlenden SecurityContext nicht durchgeführt werden. Der SecurityContext wird hier lediglich aus dem Hello- RemoteContext-Objekt extrahiert (Implementierung des IntegratedSecurityContext-Interface) und über den SecurityContextHolder verfügbar gemacht. Als Erweiterung des Aspekts könnte man eine Gültigkeitsprüfung des SecurityContext durchführen, indem Listing 3 <security:http auto-config= true > <security:intercept-url pattern= /secure/index.jsp access= ROLE_USER, ROLE_ADMIN, ROLE_GUEST /> <security:intercept-url pattern= /secure/** access= IS_AUTHENTICATED_REMEMBERED /> <security:intercept-url pattern= /*.do access= IS_AUTHENTICATED_REMEMBERED /> <security:intercept-url pattern= /** access= IS_AUTHENTICATED_ANONY- MOUSLY /> </security:http> <security:authentication-provider user-service-ref= userdetailsservice /> <util:properties id= myjndiproperties location= classpath:jndi.properties /> <jee:remote-slsb id= helloworldservice jndi-name= ejb/helloworldserviceexporter business-interface= de.opitzconsulting.helloremote. service.ihelloworldservice environment-ref= myjndiproperties > </jee:remote-slsb> <jee:remote-slsb id= userdetailsservice jndi-name= ejb/userdetailsserviceexporter business-interface= org.springframework.security. userdetails.userdetailsservice environment-ref= myjndiproperties > </jee:remote-slsb> Listing 4 <!-- Laden des Web-ApplicationContext --> <context-param> <param-name>contextconfiglocation</param-name> <param-value>/web-inf/classes/ applicationcontext-security-web.xml</param-value> </context-param> <!-- Einbindung von --> <filter> <filter-name>springsecurityfilterchain</filter-name> <filter-class>org.springframework.web.filter. DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springsecurityfilterchain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <listener> <listener-class>org.springframework.web.context. ContextLoaderListener</listener-class> </listener> Listing 5 <bean id= securitycontextextractoraspect class=»de.opitzconsulting.helloremote.security. SecurityContextExtractorAspect /> <aop:aspect-autoproxy proxy-target-class= false /> <security:authentication-provider user-service-ref= userdetailsservice /> <security:user-service id= userdetailsservice > <security:user name= admin password= admin authorities= ROLE_ADMIN /> <security:user name= user password= user authorities= ROLE_USER /> <security:user name= guest password= guest authorities= ROLE_GUEST /> </security:user-service> <bean id= helloworldservice class= de.opitzconsulting.helloremote.service. HelloWorldService ></bean> <security:global-method-security secured-annotations= enabled /> Listing argnames = secured ) public void extractsecuritycontext(joinpoint jp, Secured secured) throws Throwable { Object[] parameters = jp.getargs(); if (parameters!= null && parameters[0]!= null && parameters[0] instanceof IntegratedSecurityContext) { IntegratedSecurityContext integratedsecuritycontext = (IntegratedSecurityContext) parameters[0]; SecurityContext securitycontext = integratedsecuritycontext.getsecuritycontext(); if (securitycontext == null) { final String msg = No SecurityContext found in integratedsecuritycontext ; log.error(msg); throw new AuthenticationCredentialsNotFound Exception(msg); SecurityContextHolder.setContext(securityContext); else { final String msg = No authentication object found! ; log.error(msg); throw new AuthenticationCredentialsNotFound Exception(msg); 62 javamagazin

7 eine erneute serverseitige Authentifizierung und Autorisierung vorgenommen wird. Der dadurch wiederholten Abfrage an Benutzerinformationen könnte man durch Caching-Mechanismen entgegenwirken. Allerdings sollte dabei ein angemessenes Trade-Off zwischen Sicherheit und Performance nicht außer Acht gelassen werden. Mit der einfachen Angabe von <security:global-method-security secured-annotations="enabled" /> wird schließlich die Verwendung Secured-Annotationen im Application- Context aktiviert. Die Sicherheitsmechanismen der Webschicht (Login) hat der Benutzer nach erfolgreicher Authentifizierung bereits durchlaufen. Nun wollen wir testen, ob die Sicherheitsmechanismen der Businessschicht funktionieren. Ein Klick auf den Link sayhello liefert die erlaubte Begrüßung Hello User zurück. Beim Aufruf der Methode sayhelloto- Admin wird allerdings eine org.springframework.security.accessdeniedexception geworfen. Da die Methode zuvor mit der ADMIN") annotiert wurde, wird korrekterweise diese von org.springframework. security.springsecurityexception abgeleitete Exception geworfen, die nur Benutzern mit der Rolle "ROLE_ADMIN" den Zugriff gewährt. Fazit Wir haben hier eine Möglichkeit der Übertragung von Sicherheitsinformationen in verteilten Anwendungen auf Basis der EJB-2-Spezifikation vorgestellt. Durch die Kombination der deklarativen Konfiguration in und den Mitteln der aspektorientierten Programmierung (Spring AOP) ist eine relativ transparente Übertragung des Sicherheitskontexts SecurityContext zwischen Anwendungsebenen möglich. Voraussetzung dafür ist allerdings die Bereitstellung eines Anwendungskontexts in den Methoden der öffentlichen Schnittstellen. Mit der Einführung des Security Namespace in wurde zudem die Konfiguration stark vereinfacht, sodass eine Grundkonfiguration schon mit wenigen Einstellungen erreicht werden kann. Dank der vielfältigen Integrationsmöglichkeiten von kann die Anwendung auch nachträglich an die eigenen Sicherheitsanforderungen flexibel angepasst werden. Anzeige Dipl. Wirt.-Inf. Michael Stähler ist Berater bei der Opitz Consulting GmbH. Er ist seit einigen Jahren in der objektorientierten Softwareentwicklung in Java tätig. Sein Schwerpunkt liegt in der Entwicklung von Enterprise-Applikationen der Java EE speziell im Themenbereich der Integration von Unternehmensanwendungen. Kontakt: michael.staehler@opitz-consulting.de. Links & Literatur [1] de.wikipedia.org/wiki/aspektorientierte_programmierung [2] Cross Cutting Concern: de.wikipedia.org/wiki/cross-cutting_concern [3] static.springframework.org/spring-security/site/index.html [4] Spring Framework: [5] Convention over Configuration: en.wikipedia.org/wiki/convention_over_ Configuration [6] [7] Public Key Infrastructure X.509: [8] Reference Documentation: static.springframework.org/ spring-security/site/reference/html/springsecurity.html [9] SecurityContextHolder: static.springframework.org/spring-security/site/ reference/html/technical-overview.html#d4e580 [10] java.sun.com/blueprints/corej2eepatterns/patterns/businessdelegate.html [11] static.springframework.org/spring/docs/2.0.x/reference/aop-api.html