Standard für Authentifzierung und Autorisierung

[deamon]

Hallo,

Welche Schnittstelle zur Ermittlung des aktiven Nutzers und dessen Rollen ist für eine Komponente, die in verschiedensten Serveranwendungen eingesetzt werden soll, am geeignetsten?

Die Authentifizierung kann man sicher gut außerhalb eine Komponente erledigen (durch den Container). Aber die Autorisierung muss schon in die Anwendung eingewoben sein. Die Anwendung muss wissen, wer etwas tut und welche Rechte (Rollen) er hat.

Wenn ich zum Beispiel ein Wiki-Modul entwickle, das in verschiedene Anwendungen eingebunden werden können soll, ist ein einheitlicher Ansatz für die Authentifizierung und Autorisierung erforderlich. Bei einer Wiki-Seite wird der Name des Autors benötigt, um festzuhalten, wer die Änderung gemacht hat und evtl. muss der Nutzer auch eine bestimmte Rolle haben, um die Änderung überhaupt durchführen zu können.

Wenn man sich auf Webanwendungen beschränkt, wäre die Verwendung von
javax.servlet.http.HttpServletRequest.getUserPrincipal() und
javax.servlet.http.HttpServletRequest.isUserInRole(String role)
denkbar. Aber ist das so allgemein akzeptiert, dass man darauf in einer vielfältig einsetzbaren Komponente bauen kann?

Wie ist das Verhältnis diese Methoden zu JAAS? Sehe ich es richtig, dass der Servlet-Container JAAS implementiert, da getUserPrincipal() ein Principal-Objekt liefert, das in der (JAAS?)-Schnittstelle java.security.Principal definiert ist. Aber was ist mit den Rollen? Dafür scheint JAAS nichts zu bieten. Stattdessen wird das in HttpServletRequest geregelt. JAAS enthält dafür "Permissions", die für mich als konkurrierender Ansatz erscheinen.

Wie sieht es mit Spring Security aus? Damit kann man zwar alle möglichen Authentifizierungsverfahren nutzen, aber ist die Autorisierung nicht ein eigener Weg, der nichts mit JAAS oder dem Verfahren von HttpServletRequest zu tun hat? Anders gefragt: basiert Spring Security auf allgemein anerkannten Schnittstellen, die eine damit abgesicherte Softwarekomponente leicht in andere Systeme integrierbar machen?

Gruß
Christian

 

[ps]

Ich habe mich nach viel lesen und noch mehr Nachdenken für einen eigenen Ansatz zur Authentifizierung & Authorisierung entschieden. JAAS ist IMHO nur dann wirklich sinnvoll wenn sich die Anwendung in eine bereits vorhandene Enterprise-Infrastruktur integrieren muss. Man handelt sich damit auch eine sehr technologiespezifische Abhängigkeit ein.

Letztendlich kam ich zu dem Schluss in meiner anwendung einfach zwei eigene Interfaces zu implementieren: Authorizer und Authenticator. Muss meine Anwendung sich irgendwo einfügen, kann ich die Implementation jederzeit austauschen - und so auch sehr einfach ein JAAS Modul bauen wenn die Anforderung kommt.

Evtl. ist auch http://www.jsecurity.org interessant.

 

[byte]

http://www.acegisecurity.org/ bzw. jetzt http://static.springframework.org/spring-security/site/index.html

 

[deamon]

Danke für eure Antworten.

Ich habe noch ein bisschen recherchiert und bin zu folgendem (vorläufigen Ergebnis gekommen):
Es scheint so, als wäre der Standard die Methoden
* getCallerPrincipal bzw. isCallerInRole für EJB und
* getUserPrincipal bzw. isUserInRole für Servlets
zu verwenden.

JAAS steht nach meinen Recherchen etwas daneben und hat in Java EE eher am Rande Bedeutung:
http://today.java.net/pub/a/today/2006/09/14/using-jaas-in-ee-and-soa.html

Spring Security scheint neben JAAS und neben den Mechanismen von Java EE zu stehen.

Wenn man also eine Komponente, die Authentifizierung und Autorisierung benötigt, entwickeln möchte und auf einen breit akzeptierten Standard setzen will, dürfte wohl der Java-EE-Ansatz der beste sein.

Mich würde in diesem Zusammenhang trotzdem eine Einschätzung zur Verbreitung/Akzeptanz/Interoperabilität von Spring Security interessieren. Für mich sieht es im Moment so aus, dass eine Anwendung, die auf Spring Security basiert, sich gut in eine Umgebung einbinden lässt, die ebenfalls darauf basiert. Es ist sozusagen ein eigenes Ökosystem. Oder sehe ich das falsch?

JSecurity gefällt mir übrigens nicht so richtig, weil da Exceptions für ganz normale Zustände (falsches Passwort) missbraucht werden. Keine Ahnung, ob das die einzige Designschwäche ist, aber ich finde das schon ziemlich übel und vermute weitere Sünden.

Gruß
Christian

 

[ps]

Mich würde in diesem Zusammenhang trotzdem eine Einschätzung zur Verbreitung/Akzeptanz/Interoperabilität von Spring Security interessieren. Für mich sieht es im Moment so aus, dass eine Anwendung, die auf Spring Security basiert, sich gut in eine Umgebung einbinden lässt, die ebenfalls darauf basiert. Es ist sozusagen ein eigenes Ökosystem. Oder sehe ich das falsch?

Das sehe ich ähnlich. Baut man mit Spring, greift man auf Spring Komponenten zurück. Entwickelt man nicht mit Spring, möchte man es vermeiden sich wegen einer einzigen Komponente den ganzen Container aufzuhalsen.

 

[byte]

Das einzige was man sich dabei aufhalst, ist Springs DI. Wenn man das nicht will, sollte man einen Bogen um Spring machen. Ansonsten ist Spring aber modular aufgebaut und man nutzt nur die Teile des Frameworks, die einen interessieren.