WJAX: Mike Wiesner: Security Last - Sicherheitsentscheidungen spät treffen Warum Security Last? Nun ja, weil "Security nervt", wie Martin Lippert es gesagt hat. Außerdem bringt Security erstmal wenig Feedback, bei agiler Entwicklung will man erstmal Feedback zu anderen Themen als Security. Und eine 100% sichere Anwendung ohne Funktion macht auch kein Sinn. Außerdem muss ich Security jeweils mit ändern und es erschwert das Testen des Businesscodes. Und die Architektur muss sich an den Anforderungen orientieren - und daran muss sich auch Security orientieren.

Also: Soll man Security einfach ignorieren? Nein, man sollte es nur am Ende beachten. Dass ist auch nicht mehr Aufwand, wenn man die richtigen Tools hat. Meistens ist es sogar weniger Aufwand, man kann die Anwendungen ohne Security testen und man muss sie nicht ständig mit ändern.

Wie bekomme ich es hin, den Code im Nachhinein zu ändern? Eine Möglichkeit ist AspectJ, dass es mir ermöglicht Security als Aspekt zum Code hinzuzufügen. Außerdem ist dann die Security im Byte-Code enthalten, man kann sie nicht einfach abschalten. Allerdings benötigt man etwas Einarbeitung. Eine andere Lösung ist Spring AOP, dass mir im wesentlichen dieselben Möglichkeiten wie AspectJ bietet. Dann hat man allerdings keine Compile-Time-Security, die Sicherheit wird erst zu Laufzeit eingefügt.

Als vorbereitetes Framework auf dieser Basis gibt es Spring Security (Acegi), dass bereits eine Aspekt-orientierte Security-Lösung implementiert. Spring Security funktioniert mit Spring AOP und AspectJ. Fehlt nur noch das Testen - hier kann man Tests mit JUnit und Fit implementieren.

Wie bekommt man Security Last jetzt hin? Zunächst benötigt man für die Authentifizierung des Benutzer - den bekommt man bei Spring Security über den SecurityContextHolder. Dort kann man auch die Authentifizerung ablegen. Der wird dann am Thread gehalten, kann an die Child-Threads vererbt werden, in einer Umgebungsvariable liegen, in der HTTP-Session gespeichert sein usw. - das ist konfigurierbar. Damit man die Authentifizierung wirklich vornehmen kann, muss man einen AuthenticationManager nutzen, der die Authentifizierungs-Informationen überprüft. Dabei kann man unterschiedliche Authentifizierungs-Verfahren nutzen und man muss dazu nur noch einen Provider für die jeweilige Authentifizierungs-Technologie hinzufügen.

Bei der Authorisierung muss man im klassischen Modell in jeder Methode die Rollen überprüfen - was aufwändig ist, vergessen werden kann und Wissen über die Rollen voraussetzt. Mit Security Last schreibt man solchen Code nicht und hat dadurch die Probleme nicht mehr. Dazu nutzt man einen Servlet Filter für die URLs oder einen AOP Interceptor, der die Methoden-Aufrufe abfängt und die Security bearbeitet. Dort kann man dann definieren, welche URLs oder Methoden von einer bestimmten Rollen aufgerufen werden können - logischerweise in der Spring-Konfiguration. Oder man schreibt passende Annotationen.

Im Gegensatz zu sonstigen Ansätzen zeigt Mike dann, dass man in den Annotationen oder der Konfiguration Rechte konfigurieren sollte und keine Rollen. Dadurch hat man den Vorteil, dass der Code nur Rechte kennt und keine Rollen - dadurch ist man flexibler. Wenn es neue Rollen gibt oder eine Rolle neue Rechte bekommt - auch zur Laufzeit - muss man einfach nur irgendwo ein Eintrag ändern, aber den Code nicht anfassen.

Ein weiteres Problem ist, dass man dynamische Rechte haben muss: Nur bestimmte Nutzer dürfen bestimmte Datensätze bearbeiten. Dazu kann man mit Spring Security auch nutzen, indem man den Zugriff über ACLs löst und diese ACLs ad-hoc anhand der Eigenschaften der Objekte berechnet. Das bedeutet auch, dass es eine Defense-In-Depth gibt, d.h. im System selber gibt es noch Verteidigungs-Linien zum Beispiel an den DAO-Schnittstellen. Wenn man es nun schafft, per SQL-Injection Datensätze auszulesen, auf die man keinen Zugriff hat, wird durch Spring Security die Ergebnisse trotzdem verworfen.

Bei Tests kann man durch diese Separierung den Business-Code ohne Security testen und die Security ohne den Business-Code. Und zwar recht einfach: Für die Tests der Geschäftslogik kann man die Security als Aspekt deaktivieren. Für Security-Tests ersetzt man die Logik durch eine einfache Variante, die keine echte Funktionalität hat. Mit Fit kann man die Tests einfach als Word-Dokumente schreiben und dann ausführen lassen.

Fazit: Security Last ist technisch machbar - und dabei wird es auch leichter testbar und leichter änderbar.

Labels: Acegi, Mike Wiesner, Spring Security, WJAX

  ¶ 14:55 2 comments

  WJAX: Jürgen Höller: Leichtgewichtige Transaktionen Transaktions-Management ist mit Mythen belegt - so zum Beispiel, dass man eigentlich immer XA benötigt und Two Phase Commit. Das ist natürlich nicht der Fall, wenn man nur eine Ressource hat. Ebenfalls ist es nicht notwendig, eine O/R-Mapper-Integration über XA zu integrieren. Ebenfalls ist nicht unbedingt notwendig, bei der Integration von JMS und JDBC XA-Transaktionen zu verwenden. Und natürlich muss man nicht EJB verwenden, um Transaktions-Attribute deklarativ zu verteilen. Ebenfalls ist es nicht notwendig, Transaktionen nur in einem Application Server funktionieren. Selbst die Weitergabe des Transaktions-Kontext bei verteilten Aufrufen ist eine Sache der RMI-Implementierung und des Transaction-Managers - EJB muss nicht unbedingt involviert sein. Dabei geht es wirklich um Transaktione verschiedener Server - nicht nur die Nutzung mehrerer Ressourcen auf einem Server.

Wann soll man JTA-Transaktionen und wann native Transaktionen verwenden? Transaktions-Demarkation ist unabhängig davon - irgendwie muss das im Code ausgedrückt werden. Klassisch in XML, Annotationen oder im Code. EJB bietet solche Features - Spring natürlich auch. Dabei kann man nicht nur die Propagation einstellen, sondern auch die Isolation oder ob die Transaktion Read-Only ist sowie einen Timeout. Read-Only ist eine Optimierung, die bei einem O/R-Mapper die Überprüfung auf Änderungen an den Objekten abschaltet. Die Propagation regelt, wann eine neue Transaktion gestartet werden soll. Diese Verhaltens-Regeln sind unabhängig vom Transaction-Manager. Allerdings können nur wenige Infrastrukturen geschachtelte Transaktionen unterstützen. Das kann zum Beispiel ein Vorteil sein, wenn man sehr viele INSERTs macht und nicht alle Zurück-Rollen will, wenn irgendwo ein Fehler auftritt. Analog Möglichkeiten bieten JDBC-Treiber, die dann zum Beispiel bei einem Master-Slave-Cluster optimieren können.

Zum Setzen solcher Optionen bietet es sich an, in einer XML-Konfiguration die Transaktionen anhand von Namens-Konventionen zu definieren.

Letztendlich wird dann durch die Wahl des richtigen Transaction-Managers definiert, wie die konfigurierten Transaktionen wirklich umgesetzt werden. Und hier kommt man oft um XA herum. Aber warum nicht einfach XA verwenden? Ein Grund ist, dass XA nicht in allen Umgebungen zur Verfügung steht. Man benötigt nicht nur einen passenden Koordinator, sondern auch XA-fähige Ressourcen. Und außerdem fügt XA zur Laufzeit einen Overhead in das System ein. Der ist nicht gering, weil es komplex ist, die Garantien des XA-Protokolls tatsächlich umzusetzen. Ein Problem ist, dass der Koordinator immer dazu in der Lage sein muss, nach einem Absturz wieder aufzusetzen. Das muss in eine Datei gespeichert werden, was eben ein echter Overhead ist. Alternativ kann man eine nativen Transaction-Manager verwenden, wie es ihn in Spring für JDBC, Hibernate, JPA, JDO und JMS gibt. Dazu reicht ein einfacher Treiber - man benötigt kein XA oder ähnliches. Aber das geht nur, wenn es nur eine Ressource gibt. Der DataSourceTransactionManager bespielsweise kann native JDBC-Transaktionen unterstützen einschließlich des Isolations-Levels und verschachtelter Transaktionen. Dazu benötigt man nur einen normale JDBC-DataSource.

Mit diesen nativen Transaktionen kommt man sehr weit - es ist weit mehr als eine letzte Möglichkeit, wenn es nichts anderes gibt. Man kann die volle Mächtigkeit der Transaktionen aus der Datenbank verwenden und es ist leicht, das System aufzusetzen. Und man kann ihn auch in einer Java-EE-Umgebung verwenden - sogar mit Java-EE-DataSources. JTA ist natürlich auch eine Option - wenn man es benötigt. Der Code bleibt davon bei Spring unbeeinflusst. Es ist also nur eine Entscheidung, die man beim Deployment und der Konfiguration treffen muss.
Oder man verwendet einen integrierten Transaktions-Manager wie zum Beispiel ObjectWeb JOTM mit XAPool, der Geronimo Transaction Manager oder Atomikos, der mittlerweile Open Source ist. Dadurch kann man XA-Transaktionen auch auf einem Tomcat-Web-Server verwenden. Aber an sich ist die Wahl des Transaction-Managers sowieso etwas, was man auch erst beim Deployment entschieden wird - und dabei kann das Monitoring der JTA-Transaktionen in einem Application Server ein wichtiger Punkt sein, weil dadurch der Betrieb die Anwendung besser betreuen kann. Allerdings bekommt man bei den JTA-Transaktionen keine Möglichkeit, geschachtelte Transaktionen zu unterstützen.

Bei Spring ist die Nutzung der Transaktionen transparent, d.h. man muss nichts besonderes machen, damit der Persistenz-Code an den Transaktionen teilnimmt. Dabei wird auch z.B. automatisch die richtige Hibernate-Session für die aktuelle Transaktion verwendet. Bei JMS gibt es bei Transaktionen die Möglichkeit, per XA dafür zu sorgen, dass sowohl die Verarbeitung der Nachrichten bestätigt und auch die Datenbank-Transaktionen dann abgeschlossen ist. Wenn man kein XA verwendet, bekommt man die Nachricht eventuell ein zweites Mal, was nicht sehr schlimm ist in den meisten Szenarien, aber deutlich schneller ist.

Fazit: Viele Anwendungen könnten mit nativen Transaktionen funktionieren - und zwar wesentlich effektiver.

Labels: Jürgen Höller, Spring, WJAX

  ¶ 18:35 1 comments

  Spring Day WJAX: Martin Marinschek: JSF, Spring, JPA optimal vernetzen Dieser Vortrag nimmt sich recht viel vor: Drei Technologien, die einen vollständigen Stack bieten, werden hier kombiniert. JSF hat den Vorteil, dass es einen Standard für ein Web-Komponenten-Modell ist, so dass man viele vordefinierte Komponenten bekommt. Spring als Dependency Injection Lösung ist mehr oder minder offensichtlich und JPA ist wiederrum ein offener Standard, auf den auch Hibernate als wichtiges O/R-Mapper-Produkt setzt.

Die Integration von Spring und JSF bietet die Möglichkeit, statt Managed Beans Spring-Beans zu verwenden. Dadurch hat man dann AOP, Autowiring usw. - und trotzdem sehen die Spring-Beans wie normale Managed Beans aus. Die Integration von JPA ist recht einfach, man muss nur die entsprechenden Annotationen scharf schalten, das Transaction-Management aktivieren usw. Hier findet man auch ein passendes Demo-Projekt.

Normalerweise hat man in diesem Kontext das Problem, dass man nach dem Ende der Session keine Daten mehr nachladen kann. Eine Lösung ist dann, die Objekte in Data-Transfer-Objects zu überführen, die dann das jeweilig gewünschte Objekt-Netz vollständig enthält. Dazu muss man natürlich eine Konvertierung bauen, was viel überflüssigen Code bedingt. Oder man kann es generieren lassen, was auch ein problem sein kann. Also sollte man konfiguriertes Klonen ermöglichen.

Eine andere Möglichkeit ist es, die Session über die gesamte Conversation offen zu halten - also über die Grenzen eines einzelnen Requests hinaus. Dadurch muss man die Objekte nicht mehr in DTOs konvertieren. Andere Projekte, die nicht nur ein Web-Frontend anbieten, müssen dennoch DTOs verwenden. Und man kann kein Fail-Over pro Request machen, weil die Session dann auf dem Rechner nach dem Fail-Over nicht unbedingt zur Verfügung stehen muss.

Die Persistence-Session ist natürlich nicht dasselbe wie eine HTTP-Session. Pro Request ist zu kurz - also muss man etwas anderes haben. Also zum Beispiel eine Conversation. Dazu kann man Orchestra aus dem MyFaces-Projekt verwenden, was eine JSF-Erweiterung ist, die so etwas bietet. Diese Scope existiert dann als Spring-Scope und ist in der Spring-Konfiguration verwendbar. Dazu muss man dann natürlich das aop:scoped-proxy-Feature benutzen, um die Beans auch zum Beispiel in ein Singleton zu injizieren und dann jeweils die richtige Bean aus der Conversation zu bekommen.

Man kann auch direkt auf die Conversation zugreifen durch das Interface ConversationAware. Und man kann auch informiert werden, wenn eine Bean in die Conversation aufgenommen wird oder entfernt wird.

Die Conversation kann dann explizit programmatisch, durch einen Timeout oder als Aktion in den JSF-Beans beendet werden, so dass es dann auch keine Speicher-Lecks mehr wegen überflüssigen Daten in der Session gibt.

Labels: JPA, JSF, Martin Marinschek, Spring, Spring Day, WJAX

  ¶ 16:32 0 comments

  Spring Day WJAX: Christian Dupuis: Spring IDE In diesem Vortrag sprach Christian Dupuis, mein zukünftiger Kollege, über Spring IDE. Dabei sprach er über den Anspruch, mit der Spring IDE das Editieren der Spring-Konfigurationen soweit zu vereinfachen, wie Spring allgemein das Leben einfacher macht. Mit Config Sets kann man dann mehrere Dateien zusammenfassen. Intern wird dabei für die Validierung ein eigener Builder konfiguriert, um die Dateien zu validieren. In Zukunft wird dabei sogar Autowiring unterstützt. Man kann auch nach Beans suchen. Ein Feature, dass ich auch nicht kannte, ist der Open Bean-Dialog - er sucht eine Bean in der Konfiguration. Das ganze ist ein angepasster XML-Editor, der Class-Code-Completition hat usw.

Vor allem kann man mit Spring IDE vor allem Web Flows grafisch editieren. Dabei wird auch die Möglichkeit geboten, auf die Spring Beans zuzugreifen. Und es gibt auch die Möglichkeit, mit Spring IDE die AOP-Konfiguration zu validieren und zu sehen, wo die Pointcuts zuschlagen. Dabei kann man auch den Aspect-Visualisierung von AJDT (AspectJ Development Toolkit) aus dem Eclipse-Projekt verwenden. Version 2.0.2 ist die nächste Version und enthält auch schon teilweisen Support für Spring 2.5 - er wird jetzt sehr bald erscheinen. Also funktioniert zum Beispiel der bean()-Pointcut, geht und auch Spring JavaConfig sowie Spring Dynamic Modules for the OSGi Services Platform. Eclipse 3.3. und 3.4M3 wird genauso unterstützt wie WTP 2 (Web Tools Platform).

Spring IDE ist ansonsten in sehr vielen Produkten integriert. Dazu zählt Exadel Studio, MyEclipse, Lomboz Eclipse Distribution und Red Hat Developer Studio. In Zukunft wird es die Möglichkeit geben, auf einen Task fokussieren, also ein Bug-Fix zum Beispiel. Dann sieht man nur noch die Files, die man für den Fix braucht. Das sind Features von Mylyn. Spring IDE wird mit Mylyn integriert und bildet dann die Basis für die Spring Tools Suite. Es wird außerdem in der Tool Suite Unterstützung für einen Jump Start geben und zu Spring Experience im Dezember sollte auch schon die erste Demo da sein.

Labels: Christian Dupuis, Spring Day, Spring IDE, Spring Tool Suite, WJAX

  ¶ 15:58 0 comments

  Spring Day WJAX: Jürgen Höller: Spring Framework 2.5: New Features and Enhancements Jürgens Vortrag war der erste Vortrag über Spring 2.5 überhaupt - schon fast eine Ehre für die WJAX.

Er began mit dem Java 6, Java EE 5 und OSGi Support in Spring 2.5. In Spring 2.5 wird JDK 1.6 unterstützt. JDK 1.5 und 1.4 wird weiterhin unterstützt - JDK 1.3 ist nicht mehr supported, weil es auch seinen End of Live erreicht hat. Konkret bedeutet das die Unterstützung von JDBC 4.0, JMX MXBeans und der JDK ServiceLoader API.

Java EE 5 - also Servlet 2.5, JSP 2.1 und JSF 1.2 - wird unterstützt. Damit uch die JSR-250 Annotationen, die Standards für Dependency Injection darstellen. Eine interessante neue Möglichkeit ist es, einen Spring ApplicationContext als RAR-File zu verpacken. Das ist ein Teil von JCA, das ursprünglich für die Integration von Host-System in Java EE gedacht war. Dadurch gibt es eine gute Deployment-Einheit für Spring-Anwendungen in einem Application-Server. Vorher wurden oft dazu WAR-Files verwendet, die aber gar keine Web-Anwendung enthalten haben. Dadurch kann man auch Application Server Features wie JMX oder JTA verwenden.

Die WebSphere-Unterstützung ist besser geworden, d.h. er ist jetzt offiziell unterstützt von IBM. Dabei kann man nun auch Transaktione auf WebSphere unterbrechen, dazu gibt es den WebSphereUowTransactionManager. Oder man nutzt einfach die neue Konfiguration, der automatisch den besten Transaction-Manager für die Umgebung nutzt.

Beim OSGi-Support wird nun Spring als Bundles verpackt und können in einer OSGi-Umgebung nun direkt verwendet werden. Die eigentlich Integration ist das Spring Dynamic Modules Projekt, das zuvor Spring OSGi hieß. OSGi bietet eine Alternative zum Deployment in einem Java EE Application Server. Damit wird OSGi zu einer Alternative - eine Integration von Java EE mit OSGi ist eher schwierig. Spring bietet Unterstützung für beides und wird dadurch eine interessante Plattform.

Das nächste Thema ist die Annotations-basierte Konfiguration. Dazu zählt Unterstützung für JSR 250 (Common Annotations), aber auch diverse eigene Annotations. Zu JSR 250 zählt @PostConstruct und @PreDestroy für Initialisierungs-Methoden und Aufräum-Methoden. @Resource bietet die Möglichkeit, sich andere Beans injizieren zu lassen. Bisher sind die nur in Servlets und JSF 1.2 Managed Beans nutzbar - und ohne Spring nicht in "normalen" Java-Klassen - ein deutlicher Vorteil für Spring. Übrigens kann @Resource auch auf Felder angewendet werden. Der Name innerhalb der Annotation wird als Spring-Bean-Name verwendet und nicht in einen JNDI-Namen wie es sonst bei Java EE 5 der Fall wäre. Auch @WebServiceRef für JAX-WS Web-Services, @EJB für die Injizierung von EJB 3 Beans, @TransactionAttribute als Transaktions-Attribut aus EJB 3 sowie @PersistenceContext bzw. @PersistenceUnit für JPA Ressourcen wird unterstützt. Besonders interessant ist @Autowired, mit der man auf Felder, Setter-Methoden oder Konstruktoren Autowiring nach Typ bei bestimmten Eigenschaften eines Spring-Bean aktivieren kann. Durch diese Begrenzung auf spezifische Properties kann Autowiring in Zukunft wesentlich nutzbarer werden. Durch @Qualifier kann man die Auswahl noch weiter einschränken. Dazu wird das qualifier-Tag in der Spring-Konfiguration verwendet. Alternativ kann man auch eine eigene Annotation verwenden.

In dem neuen context-XML-Namespace gibt es einige neue Elemente der Konfiguration. Dazu zählt context:property-placeholder für den PropertyPlaceholderConfigurer. context:mbean-export exportiert die mit den richtigen Annotationen versehenen Spring-Beans über JMX. Mit context:annotation-config kann man alle JSR-250-Annotationen aktivieren. Und context:component-scan macht aus den richtig annotierten Klassen automatisch Spring-Beans. Dazu werden Stereotype-Annotationen verwendet, die jeweils die Klasse als bestimmte Komponente markiert. Dazu zählt zum Beispiel @Component, die einfach eine Spring-Bean aus der Klasse macht.

Ebenfalls neu ist die Unterstützung für Annotationen zur Definition von Web-Controllern. Dazu muss man lediglich mit @Controller die Klasse annotieren. Innerhalb der Klasse kann man dann mit @RequestMapping, @RequestParam und @ModelAttribute das Mapping von Objekten und Methoden auf HTTP-Request definieren. Dieses Modell macht die Entwicklung eines Controller wesentlich einfacher und eleganter.

Ebenfalls neu ist das Test-Framework. Spring hat schon länger Support für Integrations-Tests mit JUnit 3.8. Neu ist die Unterstützung für JUnit 4.4 und TestNG. Damit werden die bisher bekannten Klassen für JUnit 3.8 nicht mehr zwingend benötigt. Das PetClinic und das ImageDB Sample sind jetzt auf diese Art der Controller umgesetzt und zeigen die Nutzung sehr gut.

Ebenfalls neu ist die Möglichkeit, in den Pointcuts nun den Spring-Bean-Namen mit der bean(name)-Element zu verwenden. Außerdem bietet Spring nun Unterstützung für das AspectJ-Load-Time-Weaving. Man kann dadurch das Problem des Handling des Class-Loaders Spring überlassen. Diese Funktionalität gab es zuvor schon für JPA und funktioniuert z.B. in Tomcat, ClassFish, Web Logic 10 und OC4J. Dazu ist nur ein in der Konfiguration notwendig. Dabei wird die Umgebung untersucht und automatisch die richtige ClassLoader-Erweiterung verwendet. Dadurch wird die Nutzung von @Configurable nachhaltig vereinfacht. Auf diesen Klassen funktioniert dann auch @Autowired zum Beispiel. Ebenfalls kannman in jetzt auch den AspectJ-Modus wählen und dadurch @Transactional auch auf normalen Java-Objekten verwenden.

Neu ist auch die Unterstützung von JCA-Adaptern von JMS-Implementierungen. Ebenfalls gibt es nun einen jms-Namespace, der die Konfiguration von Listenern wesentlich vereinfacht.

Ingesamt verwendet Spring 2.5 nun also Annotationen an verschienden Stellen und wird dadurch an einigen Stellen wesentlich einfacher und mächtiger. Und auch sonst - zum Beispiel für die XML-Namespaces - gibt es deutliche Fortschritte.

Labels: Jürgen Höller, Spring 2.5, Spring Day, WJAX

  ¶ 13:04 0 comments