Rollen eines Benutzers ermitteln

[Guest]

Hallo,

im request-Objekt gibt es die Methode isUserInRole(...). Gibt es auch ne Möglichkeit, an die Rollen eines Benutzers heranzukommen, um eine entsprechende Überprüfung von eigenen Klassen vornehmen zu lassen?

 

[Gast]

Ersatzweise wäre auch die Frage, ob man an alle definierten Rollen in der Applikation herankommt. Ich benötige einfach nur eine Reihe von Rollen, die es geben kann, die aber vor Ort und Stelle erstmal nicht bekannt sind.

 

[ms]

Wo werden denn die zugewiesenen Rollen hinterlegt?
In einer Datenbank?
Wenn ja, kannst du ja direkt darauf zugreifen.

ms

 

[Gast]

Die Rollen werden im EAR-Deployment Deskriptor festgelegt, ganz n ormale J2EE-Security eben.

 

[ms]

Die Rollen selbst schon aber doch nicht die Zuweisung der Rollen an die Benutzer, oder?

ms

 

[Gast]

Die Zuweisung der Rollen zu Benutzern/-gruppen findet bei J2EE im Web Deployment Deskriptor statt. Darum geht es aber gar nicht. Ich suche nur die Überbrückung von J2EE mit einem eigenen Mini-Framework. Beide benötigen jeweils den Namen einer Gruppe zur Überprüfung, d.h. ich muss einerseits fragen, ob lt. J2EE ein bestimmter Benutzer einer Rolle zugeordnet ist, andererseits muss ich auch bei der Ressource aus meinem Framework nachfragen, ob eine bestimmte Rolle berechtigt ist.
In beiden muss also die Rolle definiert sein, ohne dass ich genau weiß, welche Rollen das später sein werden.
(später=Assembler-/Deployer-Zeit)

 

[ms]

Die Zuweisung der Rollen zu Benutzern/-gruppen findet bei J2EE im Web Deployment Deskriptor statt.

Das klingt, als wäre das allgemein gültig. Zeig mal den relevanten Teil deines deployment descriptors, damit wir wirklich vom selben sprechen. (auch wenns mit dem eigentlichen Problem anscheinend nichts zu tun hat)

Wenn die Rollen im web.xml definiert sind, dann sollte das schon mit dem Programmcode zusammenpassen. Deinem Code (Miniframework) zur Laufzeit für eine bestimmte Funktion eine Berechtigung (Rolle) setzen, die selbst zur Laufzeit definiert wird klingt sehr abenteuerlich.

ms

 

[Gast]

Also im EAR-Deployment Descriptor werden Sicherheitsrollen definiert:

<security-role>
  <role-name>admin</role-name>
</security-role>

In der web.xml stehen dann die zugehörigen Security Contraints:

<security-constraint>
    <web-resource-collection>
      <web-resource-name>Administrators</web-resource-name>
      <url-pattern>/admin/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>admin</role-name>
    </auth-constraint>
  </security-constraint>

Weiterhin muss im Lotus Notes Content erzeugt werden, der auf der Webseite angezeigt wird, insofern ein Benutzer eine bestimmte oben definierte Rolle hat. Welche Rolle er haben muss, um Zugriff auf den Content zu haben, soll in der Notes-DB festgelegt werden (pro Dokument).
Somit habe ich als Programmierer keinerlei Kenntnisse über ein Rollenkonzept, vielmehr muss ich die Konzepte von Assembler und Notes-Content-Pfleger miteinander "vergleichen".
Das ist der Teil, den ich nicht mache.

 

[Gast]

EDIT: Der letzte Satz sollte gestrichen werden. ;-)

 

[maki]

Lotus Notes

Acha, jetzt wird es klarer.

Du definierst keine Benutzer in deiner web.xml, da legst du im Moment nur fest, welche Rollen es gibt und was diese dürfen.
Was dir fehlt, ist das mapping zwischen dem was die Webanwendung an Rollen erwartet und welche Rollen dazu von extern gelinkt werden, sieh dir doch mal das role-link element an.

Das Domino Directory wird doch dann über LDAP angesprochen oder benutzt ihr Websphere? Auf jeden Fall kannst du die benötigten Info über LDAP abfragen.

 

[Gast]

Also die Anwendung läuft am Ende auf dem Websphere Application Server, die Daten für die Webseiten werden vom Domino ausgelesen, aber über die Java-API, nicht über die Web-Ports des Domino-Servers.

Die Benutzer stehen wiederrum in einem externen LDAP, mit dem Domino nichts zu tun hat. Der Websphere übernimmt die Form Authentication.

Mit sämtlichem Javacode möchte ich J2EE-konform bleiben, d.h. es sollen keine herstellerspezifischen Klassen verwendet werden, die auf einem anderen Server dann nicht vorliegen.

P.S.: Sorry für das Laien-Kauderwelsch. Bin nicht 100%ig sicher in der Materie.

 

[maki]

Die Benutzer stehen wiederrum in einem externen LDAP, mit dem Domino nichts zu tun hat. Der Websphere übernimmt die Form Authentication.

Dann hast du dir deine Antwort doch selbst schon gegeben
Wenn die Benutzer samt Rollen im LDAP stehen, lies sie doch da raus.

 

[Gast]

Nein nein, die Rollen (und - was oben nicht erkenntlich ist - die Zuordnung zu einzelnen oder allen authentifizierten Benutzern) stehen im EAR Deployment Deskriptor.

Im LDAP stehen nur Benutzeraccounts (und die vollkommen irrelevanten) Benutzergruppen. Beim Einloggen prüft der Application Server, ob dieser Account samt Passwort existiert. Danach habe ich im Request die Methoden getUserPrincipal() und isUserInRole(role) zur Verfügung. Aber hierfür brauch ich eben erstmal die möglichen Rollen.

 

[ms]

Jetzt sind wir wieder da, wo wir schon mal waren.
Wie und warum werden die Rollenzuordnungen im EAR-deployment descriptor gemacht? Bitte zeigen.
Was, wenn ein neuer Benutzer angelegt wird? Wird dann wirklich neu deployed???

ms

 

[Gast]

Wenn ein Benutzer angelegt wird, dann wird der EAR-Deployment Descriptor modifiziert (dem Benutzer werden die Rollen zugeordnet) und die Anwendung neu gestartet. Das ist alles.

 

[maki]

Hört sich alles wirr an, nix für ungut.

Zeig uns doch mal deinen EAR Deployment Diskriptor.

 

[ms]

Wenn ein Benutzer angelegt wird, dann wird der EAR-Deployment Descriptor modifiziert (dem Benutzer werden die Rollen zugeordnet) und die Anwendung neu gestartet. Das ist alles.

:autsch: Autsch!

Das würde ich nochmal überdenken!

ms