Spring-WS und Spring Security
Für die securementActions haben Sie folgende Optionen:
- UsernameToken: ein Username-Token wird hinzugefügt
- UsernameTokenSignature: ein Token und Signatur werden hinzugefügt
- Timestamp: ein Timestamp wird hinzugefügt
- Encrypt: Verschlüsselt die Nachricht
- Signature: der Response wird signiert
- NoSecurity: keine Action wird durchgeführt
Die einzelnen Optionen können mit Leerzeichen getrennt konfiguriert werden. Hierbei ist die Reihenfolge wichtig. Nachrichten, die mit einer anderen Reihenfolge abgesichert wurden, werden von der validateActions abgewiesen. Für die eigentliche Authentifizierung bietet Spring-WS einige CallbackHandler. Diese sind – bis auf einen Handler – integriert mit SpringSecurity [13]. Der SimplePasswordValidationCallbackHandler ist eine Property-basierte Authentifizierungslösung. Hier werden die Benutzerdaten direkt in der Spring-Konfiguration eingetragen:
MyPasswd
Dahingehend sind der SpringPlainTextPasswordValidationCallbackHandler und der SpringDigestPasswordValidationCallbackHandler integriert in Spring Security. Der SpringPlainTextPasswordValidationCallbackHandler verwendet einen AuthenticationManager, gegen den die übermittelten Benutzerdaten validiert werden (Listing 8).
Listing 8
...
Dagegen arbeitet der SpringDigestPasswordValidationCallbackHandler mit dem UserDetailService aus dem Spring Security Framework. Die Konfiguration ist auch einfacher (Listing 9). Zusätzlich können Daten von authentifizierten Benutzern gecacht werden.
Listing 9
...
Digitale Zertifikate
Auch dieses Feature wird von Spring-WS natürlich unterstützt. Dabei setzt die CryptofactoryBean von Spring-WS auf die CryptoFactory von WSS4J auf:
Wenn Sie ausgehende Nachrichten signieren wollen, können Sie das einfach über das Property securementActions steuern (Listing 10).
Listing 10
Eine weitere Beschreibung der Security-Features von Spring-WS führt an dieser Stelle zu weit. Falls Sie an diesem Thema interessiert sind, konsultieren Sie die Spring-WS-Dokumentation – insbesondere das Kapitel über Security [14].
Zusammenfassung
Nun neigt sich diese Artikelserie dem Ende zu. Im ersten Teil haben wir zusammen die Basics von Spring-WS kennengelernt. Dort haben wir sehr schnell einen Web Service erstellt, der zwar sehr Low-Level implementiert war, aber seinen Dienst tat. Im zweiten Teil haben wir den Web Service verbessert, da wir die direkten Zugriffe auf den Soap Body vermieden haben, indem wir aus unserem XML -Schema ein Java-API generiert haben. In diesem letzten Teil haben wir uns dem zweiten Part der Web-Service-Kommunikation zugewandt – dem Client. Auch hier haben wir einen Low-Level-Client implementiert und danach eine verbesserte Version auf Basis unserem Java-API. Und zu guter Letzt habe ich Ihnen noch einen Einblick in die Themen Test und Sicherheit bei Spring-WS gegeben. Ich hoffe, die Artikelserie hilft Ihnen bei der Verwendung von Spring-WS weiter.
Hinterlasse einen Kommentar