Verständnisfragen zu (EJB3-) Security

[Tobias]

Ok,

mein erstes EJB3 Projekt mit Benutzerverwaltung: Ich programmiere eine Anwendung mit Java Applikationsclients und EJB3. Diese Anwendung benötigt - sowohl Client- als auch Serverseitig - eine Benutzerverwaltung und ein Rollenbasiertes Sicherheitskonzept. Auf der Serverseite ließe sich das ja über deklarative Security realisieren - das würde aber vorraussetzen, dass meine Kunden neue Benutzer und Rollen direkt im Applikationsserver (JBoss) anlegen - diese Anforderung scheint mir gewagt. Und auf Clientseite funktioniert das ganze dann auch nicht, oder?

Ich weiß, das JBoss mittels JAAS die Authentifizierung erledigen lassen kann, aber kann man mittels JAAS (oder mittels EJB3-Security allgemein) im Applikationsclient Anwendungsfälle erledigen wie:

- Hat der Benutzer nicht die Berechtigung zu suchen, soll das Suchfeld ausgeblendet werden,
- Hat der Benutzer kein Schreibrecht für Datensatz XYZ, soll die entsprechende Maske nicht aufrufbar sein,
- Plugins, für die dem Benutzer kein Zugriff erteilt wurde, sollen in der Navigation nicht aufgeführt werden?

Als Alternative bleibt eigentlich nur das Schreiben einer eigenen Sicherheitsarchitektur - was wiederum den Code weniger straight-forward und unleserlicher macht. Ausserdem ist meine eigene Architektur sicher leichter angreifbar als die eingebauten Mechanismen ...

Stellt sich also die Frage: Was würdet ihr in dieser Lage tun? Ist es sinnvoll, einen eingebauten Mechanismus zu umgehen?

mpG
Tobias

Edit: Titel geändert, weil das ganze nicht nur mit EJB3-Security zu tun hat.

 

[semi]

Hallo,

das ist ein verdammt unübersichtliches Feld. JAAS orientiert sich zu sehr an den technischen
Aspekten der Sicherheit, weniger an der Semantik und ist nicht so fein gegliedert, wie du es
haben möchtest. Insbesondere dieser Teil mit Zugriff auf Datensatzebene ist sehr an die Logik
der vorliegenden Anwendung gekoppelt und schwierig durch ein Framework abzudecken.
Wenn du eine gute Lösung findest, sag bitte Bescheid. Ich habe mich mit dem Thema schon
oft beschäftigt und jedesmal lief es auf eine eigene Lösung hinaus, da mir JAAS zu unflexibel
und zu unübersichtlich war.

Gruß,
Michael

 

[Guest]

Wenn du EJB3 benutzt kannst du ein solches Sicherheitskonzept mit Annotationen und Interceptoren erreichen.
Schau dir z.B. mal http://java.sun.com/javaee/5/docs/api/javax/annotation/security/RolesAllowed.html
und http://java.sun.com/javaee/5/docs/api/javax/ejb/PostActivate.html an

 

[Guest]

serverseitig lohnt es sich imho die rollenbasierte sicherheitsarchitekur zu verwenden, nur schon aufgrund der tatsache das der server ja sowieso abgesichert werden sollte und du so flexibel für änderungen bleibst (zb. webclient whatever). wie schon angedeutet wurde musst die die präsentationslogik clientseitig selbst "absichern". es würde sich aber sicherlich anbieten dies auf der rolle aufzubauen, die du nach dem ersten request an den server ja kennst.

 

[semi]

Die Lösung mit Annotationen erscheint mir auf den ersten Blick zu statisch.
Meist gibt es sehr viele Überschneidungen zwischen den Rollen, so dass statisch eingebaute Rollenzuordnung im Code
nur Ärger bedeutet. Einfaches Beispiel: Ein Benutzer bzw. der Administrator des Systems soll befähigt werden neue
Rollen anzulegen und diesen entsprechend auch bestimmte Rechte zuzuordnen oder zu entziehen. Sind die Rollen fest
im Code "verbaut", kann man dies zur Laufzeit nicht mehr ändern. Dies ist vielleicht für kleine Anwendungen mit
einem überschaubaren Leistungsumfang praktikabel (fest vordefinierte Rollen; eine übersichtliche Anzahl; nicht
konfigurierbar).
Die Sache mit den Callbacks in EJB ist wieder zu sehr auf eine spezielle Technologie festgelegt und nicht direkt auf
andere übertragbar. Das macht sicherlich die Integration bestehender Systeme schwieriger. OK, darüber müsste
ich noch nachdenken...

Die Entscheidung über die Sicherheitsinfrastruktur eines Systems ist i.d.R. in einer sehr frühen Phase eines Projektes
fällig. Meine Erfahrung ist, dass es einerseits nicht früh genug sein kann, da es nicht unwesentlich das Design beeinflusst,
andererseits hat man anfangs noch nicht den "totalen Durchblick", was alles zum Leistungsumfang gehören soll/wird.
Das birgt dann die Gefahr in sich, dass man auf das falsche Pferd setzt und später lange Nächte mit irgendwelchen
Refactoring-Orgien verbringt, weil sich die Anforderungen "geringfügig" geändert haben (Kunde ist König oder so ).

Eine Lösung, mit der ich schon paar mal gute Erfahrung gemacht habe, war das Command Pattern mit einer Art
Permission-Injection nach der Anmeldung. Clientseitig hast du nur Proxies für alle möglichen Aktionen und die
Entscheidung was, wann und von wem aufgerufen werden kann, wird serverseitig getroffen und ist beliebig
konfigurierbar. Aber "die Lösung" habe ich leider noch nicht. Es variiert vom Projekt zu Projekt und irgendwie
erfindet man das Rad jedesmal neu.

PS: Der Threadtitel ist aber "Verständnisfragen zu EJB3 Security". Vielleicht geht nur die Phantasie mit mir durch.

Gruß,
Michael

 

[Tobias]

Meine derzeitige Lösung sieht folgendes vor:

Ein Benutzer meldet sich an der Client-Anwendung an. Die Client-Anwendung nimmt dafür Login-Daten (z.B. einen Benutzernamen und ein Passwort) entgegen, schickt diese an eine serverseitige Login-Methode, die entweder eine Exception schmeißt (Benutzerdaten nicht bekannt oder inkorrekt) oder ein User-Object zurückliefert, was den angemeldeten Benutzer repräsentiert. Mit diesem User-Object sind eine Reihe von Berechtigungen verknüpft, welche vom Applikations-Admin frei konfiguriert werden können müssen.

Hier ein UML-Diagramm von User:

+--------------+             hat                            +------------+
| UserTreeItem |------------------------------------------->| Permission |
+--------------+                                            +------------+
          ^
          |
          +------------------------+
          |                        |
+-----------+                  +------+
| Usergroup |                  | User |
+-----------+                  +------+

Die Berechtigungen des Users sind die zusammengefassten Berechtigungen all seiner UserGroups und der ihm individuell zugewiesenen Berechtigungen. Je weiter unten im Baum eine Berechtigung zugewiesen wird, desto größeres "Gewicht" hat diese Berechtigung. Dazu ein Beispiel: Ein Benutzer "Bob" gehört zur UserGroup "Kassierer". Der Gruppe der "Kassierer" ist es allgemein untersagt, den Tresor zu öffnen. "Bob" als Schichtleiter bekommt dieses Recht jedoch individuell zugewiesen. Da "Bob" unterhalb der Gruppe "Kassierer" im Baum auftaucht, ist das "Bob" individuell zugewiesene Recht bindend.

Das Abfragen der einzelnen Berechtigungen übernimmt eine Klasse SecurityManager (nicht zu Verwechseln mit dem built-in SecurityManager), welche nach der Authenfizierung auch auf dem Server benutzt werden soll (sofern nicht noch jemand mit einem genialen Gegenvorschlag kommt ).

So wie ich das sehe, ist dieses Berechtigungskonzept nicht mittels deklarativer Security in EJB3 umsetzbar. Eine eigenes Konzept (ich tendiere hier zum Einsatz von Interceptor-Methoden) erscheint mir unausweichlich.

Über eine allgemeine Diskussion zu obigem Konzept würde ich mich freuen. Mein Dank gilt jedoch schon im Vorraus allen Postern, die mit ihren obig dokumentierten Einfällen und Vorschlägen bereits ein gutes Stück vorwärts geholfen haben: Danke schön :toll: !

mpG
Tobias

 

[Guest]

Ich finde das hört sich schon gut an. Wenn du dich gegen das Interceptor Konzept von EJB3 sträubst, kannst du es ja ganz allgemein mit AOP probieren