Glassfish Custom Realm (oder wie auch immer man das löst)

[CQQL]

Hallo,
ich möchte für meine WAR eine Benutzerauthentifizierung auf Glassfish implementieren. Dafür muss ich ja einen Realm erstellen und die WAR entsprechend konfigurieren. Das letzte hab ich auch fertig und funktioniert auch alles mit dem file-Realm. Jetzt soll das ganze natürlich eine DB als Backend bekommen. Also denk ich mir (dachte ich mir vor mittlerweile 3 Tagen), JDBCRealm hört sich ja super an. Aber nix da. Ähm, wer verwendet denn so eine DB-Struktur um Benutzer und Gruppen abzubilden? Also hab ich mich dann als fröhliche googlen gemacht, aber scheinbar ist die Antwort auf meine Frage wohl "Jeder außer mir", weil es gibt nirgendwo eine Lösung dazu zu lesen oder einen einfachen Custom Realm, den man konfigurieren kann. Optimalerweise gäbe es eine Möglichkeit, dass ich einen Realm in mein EAR packen kann, der dann zum Authentifizieren auch noch auf meine EJBs zugreifen könnte. Ist das möglich? Wie machen es alle anderen? Und ich habe mir sogar schon Spring Security angetan und ausprobiert, aber das verträgt sich halt nicht so besonders toll mit EJBs.

Danke im voraus,
CQQL

 

[DerFeivel]

Willst du jetzt wie hier:

JDBC+Real@theventiblog.com

eine Datenbank benutzen, um dort deine Authentifizierungsdaten zu hinterlegen?



Oder willst du vielmehr eine eigene REALM implementieren?

Dann sollte die aber wie hier:

Because Oracle Said so

nicht in dein EAR gepackt werden sondern als Bibliothek deinem Glassfish zur Verfügung gestellt werden.

 

[CQQL]

Eigentlich möchte ich, wie im ersten Link, eine DB benutzen. Das Problem ist aber, dass ich ein Many-To-Many-Mapping zwischen Benutzern und Gruppen habe, also mit einer Link-Tabelle. Mit dieser Struktur lässt sich aber JDBC-Realm nicht verwenden. Außerdem habe ich gelesen, dass dieser ausgelesene Werte unendlich lange cacht, was bei mir jetzt auch nicht passt. Der einzige Weg, JDBCRealm zu verwenden, wäre diese 2. Tabelle über einen View zu "erstellen".

Dann werd ich wohl doch einen eigenen Realm implementieren müssen. Aber ist das normal? Muss man das für jedes Projekt machen? Hat nicht irgendjemand mal soetwas wie eine abstrakte Implementierung geschrieben, die man nur noch konfigurieren muss und die etwas offener zu DB-Strukturen ist als der vorgegebene Realm? Wie machen das denn die Leute, die selber Realms in ihren Projekten verwenden? Schreiben die sich immer selber einen?

 

[DerFeivel]

Hi,


da kommen wir der Lösung doch schonmal ein Stück näher.
Da es diese Art der Realms in anderen Applikationsservern(JBoss z.B.) gibt, hat sich die Arbeit auf jeden Fall schonmal jemand gemacht.

Hast du flexiblejdbcrealm hier :

Flexible JDBC Realm - overview

mal probiert?

Dort kannst du Benutzer-Passwort und die Benutzer-Groupen Zuordnung über jeweils ein PreparedStatement-Query ermitteln lassen (also wie im JBossAS).
Wie du Sie benutzt ist dort eigentlich auch sehr gut erklärt.


Das die Standard-JDBCRealm unendlich cached steht dort auch (???:L Wer auf solche Modelle kommt ???:L)

Wie machen das denn die Leute, die selber Realms in ihren Projekten verwenden? Schreiben die sich immer selber einen?

Die benutzen die vorgefertigten Realms, bauen ihr Datenmodell um oder wechseln im Zweifelsfall zu anderen Applikationsservern (naja, Ausfall ist hier ja nicht wirklich groß ^^)

 

[CQQL]

Den FlexibleJDBCRealm hab ich auch gefunden, wenn auch erst am Ende meiner Recherchen und dann auch nur durch Zufall. Den werd ich ausprobieren. Aber ich wollte halt wissen, wie das sonst gelöst wird. Ich hatte gehofft, dass es eine Möglichkeit gäbe, meinen Realm direkt in mein EAR zu packen und auf meine EJBs zuzugreifen.

Aber danke, dass du dich überhaupt dazu geäußert hast

 

[FArt]

Ich hatte gehofft, dass es eine Möglichkeit gäbe, meinen Realm direkt in mein EAR zu packen und auf meine EJBs zuzugreifen.

Bei JBoss geht das, aber das könnte eine AS-spezifische Funktionalität sein. Dort werden die Realms in der login-config.xml des Servers global definiert (zumindest bis JBoss 6, JBoss 7 weiß ich gerade nicht). Man kann aber auch weitere login-config.xml Dateien (z.B. mit der Applikation) deployen und dort verwenden.