Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Ein Kernanwendung soll zunächst per Web-Client benutzt werden. Der User muss sich im Web authentifizieren. Das Passort soll natürlich verschlüsselt werden. Später kann auch ein GUI oder WebService Client dazu kommen:
Was ist jetzt der "bessere" Weg:
a) Spring Security ist Teil der Webanwendung und erledigt das Ver/Entschlüsseln von Passwörtern als Teil der Webschicht.
b) Spring Security ist Teil bzw. eine dünne Schicht der Kernanwendung, so dass die Webanwendung vom Verschlüsselungsprozess nichts weiß.
Bei A) sehe ich das Problem, dass die Klients unter Umständen alle eine eigene Verschlüsselung realisieren, die nicht zwangsläufig kompatibel unter einander sein müssen. D.h. pro Client muss die Authentifizierung neu geschrieben unte konfiguriert werden (verletzt DRY)
Bei B) sehe den Nachteil, dass das Passwort nicht sofort in der Webschicht verschlüsselt, sondern als Plaintext an die Kernanwendung geschickt wird. Falls das aber über http geschieht, hat man aber immer noch https als Sicherheit.
Also wie sollte man Spring Security verwenden? Sollte es Teil des Clients, bzw. der Webschicht sein oder doch Teil der Kernanwendung?
Option A: Spring Security wird als Web-Filter konfigurativ integriert. Dabei ist die Security von der restlichen (Web-)Applikation losgeloest und kann bei bedarf geaendert oder ersetzt werden. Dabei spielt es keine Rolle, ob Username/Passwort via Basic-, Digest- oder Form-Authentication erfragt werden. Das Login sollte aber doch via https zusaetzlich verschluesselt werden, da die Basic- und Form-Authentication das Passwort in Plaintext uebermitteln. Wie gesagt dies kann alles per Spring Security Konfiguriert werden und weder deine Core- noch deine Web-Applikation braucht sich darum zu kuemmern
Option B: Wenn ich richtig verstehe soll die Web-Applikation lediglich das Login-Form anzeigen und die Kern-Applikation uebernimmt die Authentifizierung? Das bringt meines Erachtens nichts. Das Verschluesseln der Passwoerter sollte eh Spring Security uebernehmen (MD5, SHA), damit die Security Transparent bleibt und sich die Applikation nicht darum kuemmern muss. Ausserdem bleibt dann die Web-Applikation ungesichtert, welches wiederum Moeglichkeiten fuer einen Angriff bietet.
Option A: Spring Security wird als Web-Filter konfigurativ integriert. Dabei ist die Security von der restlichen (Web-)Applikation losgeloest und kann bei bedarf geaendert oder ersetzt werden. Dabei spielt es keine Rolle, ob Username/Passwort via Basic-, Digest- oder Form-Authentication erfragt werden. Das Login sollte aber doch via https zusaetzlich verschluesselt werden, da die Basic- und Form-Authentication das Passwort in Plaintext uebermitteln. Wie gesagt dies kann alles per Spring Security Konfiguriert werden und weder deine Core- noch deine Web-Applikation braucht sich darum zu kuemmern
Option B: Wenn ich richtig verstehe soll die Web-Applikation lediglich das Login-Form anzeigen und die Kern-Applikation uebernimmt die Authentifizierung? Das bringt meines Erachtens nichts. Das Verschluesseln der Passwoerter sollte eh Spring Security uebernehmen (MD5, SHA), damit die Security Transparent bleibt und sich die Applikation nicht darum kuemmern muss. Ausserdem bleibt dann die Web-Applikation ungesichtert, welches wiederum Moeglichkeiten fuer einen Angriff bietet.
Veilleicht geht auch folgende Variante zu Option B:
B.1) Spring Security sichert sowohl die Kern-Applikation (per role- bzw. method security) als auch die Web-Applikation ab.
B.2) Lediglich die Aufgabe der Passwortverwaltung wird Spring Security an die Kernapplikation übertragen. Spring Securirty leitet dabei alle Anfragen bzgl. Passwort-vergleiche, etc. an die Kern-App weiter.
Ohne B.2) hätte ich folgende Bedenken.
- Ohne die Web-Applikation bleibt die Kern-Applikation völlig ungesichert, könte z.B. keine User authentifizieren. (z.B. im consolen Modus).
Jeder neue Klient müsste die Verschlüsselungsprozedur neu entwickeln (abgesehen das DRY verletzt wird, können da auch Fehler passieren. Zum Beispiel passt der Verschlüsselungsalgo der Konsole nicht mit dem der Web-App überein, weil andere Bibliotheken oder Versionen dieser Bibliotheken verwendet werden oder der SALT müsste zwichen alle Clients synchronisiert werden)
Spring Security sollte schon durchgehend sein. D.h. es sollte in der Web- wie auch in der Kern-Applikation verwendet werden um Authentifizierung und Autorisierung zu pruefen. Somit sind beide Applikation von der via Spring Security gesichtert und muessen sich nicht selber darum kuemmer. Somit wird auch die Security von der BusinessLogik getrennt (AOP).
Wenn ein User direkt auf die Kernapplikation zugreift wird Spring Security eine Authentisierung verlangen (mit einem AuthenticationManager fuer Standalone Applikationen).
Die Passworkverschluesselung wie auch Authentisierung sollte Spring Security uebernehmen und nicht in die Businesslogik eingebaut werden (Kern-Applikation). Solche Abhaengigkeiten sollten vermieden werden.
Spring Security bietet eine breite Unterstuetzung der Passworkverschluesselung (Salt, MD5, SHA,....) und es koennen natuerlich auch eigene Mechanismen implementiert werden.
Also die beste Loesung aus meiner Sicht ist es den Security Layer und die Busineslogik zu trennen. Die Businesslogik sollte generel Abhaengigkeiten zu den Aspekten Logging, Persistenz, TransactionHandling und Security vermeiden! Damit bleibt deine Code uebersichtlich und ist einfacher zu warten und zu erweitern. Sauberer Code! Auch vereinfacht sich auch das Testing via JUnit enorm, wenn man sich nicht all diese Abhaengigkeiten mittesten muss.
Ok, ich denke im Prinzip sehe ich das auch so wie von dir geschildert.
Im Moment ist halt Spring Security noch eng mit der Web-App verzahnt, was es ja auch so sein soll/muss. Es ist in dem Maven-Projekt auch im selben Modul untergebracht wie das Web.
Falls wir dann irgendwann auf einen App-Server umziehen, dann müssen wir wohl Spring Security aus diesem Web-Kontext herauslösen und so konfigurieren, dass auch eine Konsolen-App durch die Anwendung authentifiziert werden kann.
Was ich halt vermeiden möchte ist, dass jeder Klient, in diesem Fall Tomcat, seine eigene Security-Strategie mitbringt um sich gegen die Kern-Anwendung zu authentifizieren.
Theoretisch stelle ich mir (Spring) Security also als eine dünne Schicht (dein Stichwort AOP) um die Kernanwendung vor, die in der Lage ist die Anwendung für alle möglichen Klients (Web, Konsole, etc.) transparent und einheitlich mit Security zu versorgen. Wie gesagt liegt Spring Security aber im Moment noch sehr nahe an der Web-Entwicklung (ist Teil des selben Maven-Moduls wo auch die Webentwicklung passeirt) D.h. würde ich auf dieses Web-Modul verzichten, würde ich auch den Support von Spring Security verlieren.
Ich weiß daher nicht so recht, ob es möglich ist Spring Security etwas unabhängiger von dieser Webentwicklung zu machen, im dem Sinne, dass es sein eigenes Modul in Maven erhalten. Es würde dann sowohl das Web-Modul als auch das Core-Modul (die Kernanwendung) mit Security transparent und einheitlich versorgen Ob das technisch und vom Projektaufbau her so geht , weiß ich nicht.
Welche Version von Spring Security verwendest du den? Es gibt keine Abhängigkeiten zu Web-Projekten. Aber es bittet natürlich eine sehr breite Unterstützung von Web Applikationen. Es lässt sich auch hier einfach via Konfiguration integrieren. Es ist keine Codeänderung nötig. Spring Security lässt sich problemlos auch in eine 'normale' Applikation integrieren. Natürlich musst du dann einen andern AuthentificationManager konfigurieren.
Für deine (Web-)Clients kannat du übrigens eine Defaultkonfiguration erstellen und am Besten gleich ein Maven Artifact daraus builden. Somit können alle dieselbe Konfig verwenden und es muss sich nicht jeder selber darum kümmern.
Ich benutz die Spring Security 3.0.5 (also ziemlich aktuell). Das mit der Default-Config ist ein guter Hinweise. Ich denke ich muss mch erst mal mit den Details beschäftigen :rtfm:
