# Rollen eines Benutzers ermitteln



## Guest (19. Nov 2007)

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 (19. Nov 2007)

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 (19. Nov 2007)

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

ms


----------



## Gast (19. Nov 2007)

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


----------



## ms (19. Nov 2007)

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

ms


----------



## Gast (19. Nov 2007)

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 (19. Nov 2007)

Gast hat gesagt.:
			
		

> 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 (19. Nov 2007)

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 (19. Nov 2007)

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


----------



## maki (19. Nov 2007)

> 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 (19. Nov 2007)

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 (19. Nov 2007)

> 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 (19. Nov 2007)

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 (19. Nov 2007)

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 (19. Nov 2007)

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 (19. Nov 2007)

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

Zeig uns doch mal deinen EAR Deployment Diskriptor.


----------



## ms (19. Nov 2007)

Gast hat gesagt.:
			
		

> 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


----------

