-
25.01.05 11:44 #1
- Registriert seit
- Jun 2002
- Ort
- Saarbrücken (Saarland)
- Beiträge
- 9.886
- Blog-Einträge
- 29
Hallo!
Hier mal ein kleines Beispiel für ein simples Login-Formalar, welches die Tomcat eigenen
Security-Mechanismen verwendet.
wir legen im Verzeichnis %TOMCAT_HOME%/webapps
ein neues Verzeichnis namens "a" an.
In diesem Verzeichnis "a" legen wir ein weiteres Verzeichnis namens "web-inf" an.
In Verzeichnis "a" legen wir nun die folgenden Dateien an:
login.jsp:
Code :1 2 3 4 5 6 7 8 9 10 11 12
<html> <head> <title>Login</title> </head> <body> <form action='<%= response.encodeURL("j_security_check") %>' method="POST"> Username:<input type="text" name="j_username"/><br> Password:<input type="text" name="j_password"/><br> <input type="submit" value="login"/> </form> </body> </html>
error.jsp:
Code :1
error!
index.html:
Code :1
Hallo!
Im Verzeichnis web-inf legen wir eine Datei namens web.xml an:
Code :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>A</display-name> <description> A Simple test </description> <security-constraint> <display-name>A Configuration Security Constraint</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <!-- Define the context-relative URL(s) to be protected In dem Fall wollen wir einfach unsere index.html schützen. --> <url-pattern>*.html</url-pattern> </web-resource-collection> <auth-constraint> <role-name>authUser</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>A Server Configuration Form-Based Authentication Area</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config> <security-role> <description> The role that is required to log in to the A Application </description> <role-name>authUser</role-name> </security-role> </web-app>
Nun wechseln wir ins Verzeichnis %TOMCAT_HOME%/conf
und editieren die Datei tomcat-users.xml
und ergänzen diese um folgende Einträge:
Code :1 2
<role rolename="authUser"/> <user username="testuser" password="test" roles="authUser"/>
Nun startet ihr den Tomcat über
%TOMCAT_HOME%/bin/startup.bat
und ruft die URL http://localhost:8080/a/
auf.
Standardmäßig würde Tomcat nun die index.html zeigen, da wir jedoch einen Security-Constraint
außen herum gelegt haben bekommen wir ein login-Formular zu sehen.
Wenn wir uns dort mit
user: testuser
password: test
Einloggen bekommen wir die index.html zu sehen. Geben wir andere Login Daten ein sehen wir die
error Seite.
HTH,
Gruß TomJava rocks!
How to become a good Java Programmer?
Does IT in Java and .Net
The only valid measurement of code quality: WTFs / minute
Blog
Xing
Twitter
-
Hallo Tom,
das oben von dir beschriebene habe ich ausprobiert und das klappt auch ganz gut. Ich habe das für eine Anwendung als tmporären Zugang benutzt. Jetzt stehe ich allerdings vor dem Problem, dass sich die Benutzer über LDAP authentifizieren sollen.
Dazu habe ich ein Servlet geschrieben, dass sich mit dem LDAP-Server verbindet und prüft, ob der User existiert. In meiner Login-JSP rufe ich dementsprechend auch nicht mehr "j_security_check" sondern mein Servlet auf. Allerdings glaube ich, dass ich da in einer Sackgasse stecke, denn das Servlet ruft die richtige Seite nach erfolgreichem Login zwar auf, Tomcat jedoch weiß natürlich nicht, dass der Benutzer authentifiziert ist und bei einem weiteren Klick greift wieder die web.xml Einstellung und die Login-Seite wird aufgerufen. Sprich: Login -> Suchvormular -> Klick auf "Suchen" -> Loginseite und nicht das Suchergebnis, da ich nicht weiß, wie ich dem Server mitteilen kann, dass der Benutzer gültig ist bzw. aus dem Servlet heraus die j_security_check ansprechen kann. Oder denke ich da insgesamt viel zu umständlich und das geht alles viel einfacher? Evtl. irgendwie über die server.xml und Realms, nur davon habe ich noch weniger Ahnung
Hast du oder hat sonst jemand eine Idee und kann mir helfen?
EDIT: ach ja, ist der Tomcat 4.1.31Geändert von scuffy (28.02.05 um 16:46 Uhr)
-
Hallo scuffy
über LDAP geht das auch mit den Realms allerdings hab ich den Tomcat 5.02 deshalb wird sich meine Lösung ein wenig von deiner Unterscheiden.
Ich hab in dem Verzeichnis TomcatHome/conf/Catalina/Localhost die Datei ldap-demo.xml mit dem Inhalt:
<Context
cookies="true"
crossContext="false"
docBase="ldap-demo"
override="false"
privileged="false"
path="/ldap-demo"
displayName="ldap-demo 1.0"
reloadable="true"
cachingAllowed="true"
charsetMapperClass="org.apache.catalina.util.CharsetMapper"
debug="0"
swallowOutput="false"
useNaming="true"
allowLinking="true">
<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99"
resourceName="UserDatabase"
connectionName="cn=Name,ou=Gruppe,o=Firma"
connectionPassword="pass"
connectionURL="ldap://192.168.1.1"
userBase="ou=Gruppe,,o=Firma"
userSubtree="true"
userSearch="(cn={0})"
roleBase="ou=Gruppe,o=Firma"
roleSubtree="true"
roleName="cn"
roleSearch="(uniqueMember={0})"
/>
</Context>
Du musst natürlich die Ip von deinem LDAP-Server und deinen Context eintragen. Ich denke bei Tomcat 4.x musst du alles was ich in der Datei ldap-test.xml habe in die server.xml reinschreiben.
Die web.xml sieht bei mir so aus
<web-app>
<display-name>ldap-demo 1.0</display-name>
<!-- Session Configuration -->
<session-config>
<session-timeout>10</session-timeout>
</session-config>
<!-- The Usual Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>protected</web-resource-name>
<url-pattern>/pages/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>tomcat</role-name>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>TEST-TREE</realm-name>
</login-config>
</web-app>
unterscheidet sich also nicht groß von Toms Beispiel. Ansonsten immer interessant das Realm How-To auf der Tomcat Seite http://jakarta.apache.org/tomcat/tom...alm-howto.html
-
Hallo buiters,
vielen Dank für die Antwort. Dass das wohl am elegantesten über Realms funktioniert hatte ich befürchtet und mich jetzt noch mal ausgiebig damit beschäftigt. Auf die Seite, deren Link du mir gepostet hast, bin ich auch schon gestoßen, aber ich "schwimme" hier wirklich in vielen Themen, mit denen ich bis vor wenigen Wochen noch nix zu tun hatte. Kein JSP, keine Servlets, Tomcat (was ist das) und LDAP sagten mir nichts und ich habe noch immer ein Problem mit den ganzen LDAP Parametern wie "cn" und was es da so alles gibt.
Ich habe mir deinen Vorschlag mal angesehen und versucht, das alles anzuwenden - es klappt!
Jedenfalls klappt es teilweise. Ich habe den Realm in der server.xml eingerichtet und die web.xml fast komplett übernommen. Ich kann mich mit dem LDAP-Server verbinden und er versucht auch, den user zu finden. Dabei kommt es aber zu unterschiedlichen Problemen. Er findet den Benutzer und versucht dann die "Rollen" zu ermitteln - nach dem <auth-constraint> in der web.xml sucht er dann natürlich nach role=tomcat und role=admin und kann diese natürlich nicht finden:
Code :1 2
JNDIRealm[Standalone]: Username scuffy does NOT have role tomcat JNDIRealm[Standalone]: Username scuffy does NOT have role admin
Jetzt will ich aber eigentlich nicht mit diesen roles zu tun haben
Ich möchte erst mal nur wissen, ob der Benutzer existiert und eben Benutzername und Passwort - Kombination richtig waren (Authentifikation).
Wenn das (irgend wann mal) klappt, dann möchte ich einen Schritt weiter gehen und benötige zusätzlich Informationen vom LDAP über den User. Nennen wir diese Parameter einfach x, y und z - diese enthalten Länderkennungen. Wenn alle Attribute in etwa so aussehen: x=DE,y=DE,z=DE - DANN ist der Benutzer erst berechtigt die Applikation zu benutzen (Authorisierung).
Bisher sieht mein Code so aus (Variablen geändert) server.xml:
Code :1 2 3 4 5 6 7 8
<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99" connectionURL=[url="ldaps://qwertz.com:636/"]ldaps://qwertz.com:636[/url] connectionName="uid=scuffy,o=Firma,c=DE,o=Konzern" connectionPassword="xxx" userBase="o=Konzern" userSubtree="true" userSearch="(uid={0})" />
Für die Attribute, die ich vom LDAP-Server erhalten möchte, muss ich angeblich der Zeile:
diese Attribute hinzufügen, jetzt stehe ich natürlich vor dem Rätsel wie genau das aussieht und wie ich diese Rückgabe auswerten kann...Code :1
userSearch="(uid={0})"
Meine web.xml:
.... nur der Vollständigkeit halberCode :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
<web-app> <display-name>Anwendung</display-name> <!-- Session Configuration --> <session-config> <session-timeout>10</session-timeout> </session-config> <!-- The Usual Welcome File List --> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> <security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>tomcat</role-name> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Anwendung</realm-name> </login-config> </web-app>
Vielen Dank noch mal für die bisherige Hilfe, ich bin wirklich ganz schön verzweifelt gewesen, da ich da schon ziemlich lange dran sitze und jetzt endlich das Gefühl habe "das Richtige" zu tun - jedenfalls scheint das ein recht eleganter Lösungsweg zu sein und nicht so etwas umständliches über das Servlet und dann wieder zurück ...
Wäre schön, wenn ich noch ein paar Tipps zu den roles und den Attributen bekommen könnte - vielen Dank
Grüße
ScuffyGeändert von scuffy (01.03.05 um 16:48 Uhr)
-
Hallo scuffy
eine Warnung vorweg ich beschäftige mich mit dem LDAP-Thema auch erst seit Januar diesen Jahres.
Hier mal ein link zu einer LDAP Erklärung ist halt sehr Novell spezifiesch ich fands aber ganz gut (liegt vielleicht auch daran das wir Novell einsetzten)
http://www.novell.com/documentation/edir87/index.html
vor allem die Abschnitte Understanding LDAP Services und Configuring LDAP Services könnten Interessant sein.
Um die Rollen wirst du nicht herumkommen da so wie ich das Realm-How-To verstehe diese immer mit den Rollen arbeiten. Du kannst höchstens jedem User die Rolle "Mitglied" oder so geben und auf diese Rolle dann überprüfen.
Auch das mit den verschiedenen Daten funktioniert so meiner Meinung nach nicht. Du müsstest wenn dann aufgrund dieser Daten Rollen vergeben und auf diese Rollen dann abprüfen direkt über die Realms diese Daten abzufragen halt ich für unmöglich höchstens du programmierst deine eigene Realm was möglich aber wahrscheinlich nicht in deinem Interesse ist.
userSearch="(uid={0})"
uid = {0} bedeutet das der bei der Abfrage eingegebene Username verwendet wird wenn du uid{1} machst wird der User den du unter connectionName="cn=Name,ou=Gruppe,o=Firma" angegeben hast verwendet in diesem Fall Name. Ich sehe im Moment keine Möglichkeit dort nach anderen Attributen zu suchen.
Ich hoffe ich konnte dir helfen
Gruß buiters
-
Hallo buiters,
auch erst seit Januar - naja das sind immerhin ein paar Tage länger als ich

Was die roles angeht habe ich das jetzt so gelöst, dass ich im auth-constraint jede role zulasse:
... beinahe schon zu einfach, wenn man sich ein paar Zeilen darüber das Element "url-pattern" ansiehtCode :1 2 3
<auth-constraint> <role-name>*</role-name> </auth-constraint>
Naja, aber das muss man eben wissen, dass das da auch so funktionieren könnte. Was meine Attribute angeht muss ich mal schauen, wie ich das mache.
Vielen Dank noch mal
Gruß
Scuffy
-
01.12.05 20:45 #7
- Registriert seit
- Jun 2002
- Ort
- Saarbrücken (Saarland)
- Beiträge
- 9.886
- Blog-Einträge
- 29
Hallo!
UPDATE:
- Logout-Möglichkeit eingefügt
- Verzeichnisschutz
- Anzeige des aktuellen Benutzers
Hier mal ein kleines Beispiel für ein simples Login-Formalar, welches die Tomcat eigenen
Security-Mechanismen verwendet.
wir legen im Verzeichnis %TOMCAT_HOME%/webapps
ein neues Verzeichnis namens "a" an.
In diesem Verzeichnis "a" legen wir ein weiteres Verzeichnis namens "WEB-INF" an.
In diesem Verzeichnis "a" legen wir ein weiteres Verzeichnis namens "secure" an, dies soll
unser zu schützender Bereich sein.
In Verzeichnis "a" legen wir nun die folgenden Dateien an:
login.jsp:
Code :1 2 3 4 5 6 7 8 9 10 11 12
<html> <head> <title>Login</title> </head> <body> <form action='<%= response.encodeURL("j_security_check") %>' method="POST"> Username:<input type="text" name="j_username"/><br> Password:<input type="password" name="j_password"/><br> <input type="submit" value="login"/> </form> </body> </html>
error.jsp:
Code :1
error!
index.jsp:
Code :1 2 3 4 5 6 7 8 9
<html> <head> <title>Öffentlicher Bereich</title> </head> <body> <a href="secure/secret.jsp">geschützter Bereich</a></br> <a href="logout.jsp">logout</a> </body> </html>
logout.jsp
Code :1 2 3 4
<% session.invalidate(); request.getRequestDispatcher("index.jsp").forward(request,response); %>
Im Verzeichnis secret erstellen wir nun die Datei secret.jsp
Code :1 2 3 4 5 6 7 8 9 10
<html> <head> <title>secure_area</title> </head> <body> Hallo <%=request.getUserPrincipal().getName() %>!</br> <a href="../index.jsp">index</a></br> <a href="../logout.jsp">logout</a> </body> </html>
Im Verzeichnis web-inf legen wir eine Datei namens web.xml an:
Code :1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>A</display-name> <description> A Simple test </description> <security-constraint> <display-name>A Configuration Security Constraint</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <!-- Define the context-relative URL(s) to be protected In dem Fall wollen wir einfach unsere index.html schützen. --> <url-pattern>/secure/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>authUser</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>A Server Configuration Form-Based Authentication Area</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config> <security-role> <description> The role that is required to log in to the A Application </description> <role-name>authUser</role-name> </security-role> </web-app>
Nun wechseln wir ins Verzeichnis %TOMCAT_HOME%/conf
und editieren die Datei tomcat-users.xml
und ergänzen diese um folgende Einträge:
Code :1 2
<role rolename="authUser"/> <user username="testuser" password="test" roles="authUser"/>
Nun startet ihr den Tomcat über
%TOMCAT_HOME%/bin/startup.bat
und ruft die URL http://localhost:8080/a/
auf.
Wir sehen nun die Seite index.jsp. Klicken wir auf "geschützter Bereich",
so müssen wir uns zuerst Authentifizieren. Dazu wird ein login-Formular angezeigt.
Wenn wir uns dort mit
user: testuser
password: test
einloggen bekommen wir die secret.jsp zu sehen. Geben wir "ungültige" Benutzerdaten ein
gelangen wir auf error.jsp. Sind wir auf secret.jsp können wir über einen klick auf
logout die aktuelle Session für ungültig erklären und kehren wieder auf die index.jsp Seite zurück.
Klicken wir innerhalb von secret.jsp auf den Link "index" gelangen wir wieder zurück zu index.jsp.
Klicken wir dort nun erneut auf "geschützter Bereich" gelangen wir sofort dorthin, ohne unsere
Benutzerdaten wieder eingeben zu müssen, da unsere Authentifizierungsdaten in der Session gespeichert
sind.
HTH,
Gruß TomJava rocks!
How to become a good Java Programmer?
Does IT in Java and .Net
The only valid measurement of code quality: WTFs / minute
Blog
Xing
Twitter
-
@ Thomas Danke für das plausieble Beispiel.
Ich habe das "Form" Realm mit jdbc:mysql realiesiert. Es funtioniert auch so weit.
Nun ist auf meiner Startseite ein Loginformular. Leider komme ich nicht dahinter wie ich
den user der sich auf der ersten Seite anmeldet der vorher KEINEN link innerhalb
geschützen angecklickt hat. Es ist also nicht bekannt wohin er will.
Das System soll ihn auf eine bestimmte Seite schicken
die im Formular oder der web.xml festgelegt ist.
Zürück zum Beispiel vieleicht ist es dann verstänlicher.
Es verhält sich so als ob es keine index.jsp gibt sondern nur die login.jsp.
In einem Standartformular ist innerhalb der Form Action eine Zielseite angegeben
hier geht das nicht weil. <%= response.encodeURL("j_security_check") %> als Ziel festgesetz ist.
Wie bekomme in das form action eine Zielseite und den j_security_check?
<form action='<%= response.encodeURL("j_security_check") %>' method="POST">
Das funktioniert logischer weise nicht.
<form action="/geschützterBereich.jsp?"'<%= response.encodeURL("j_security_check") %>' method="POST">
Ich habe auch innerhalb der Tomcat docu kein tag gefunden in dem
eine default Seite angeben werden kann.
Ich danke für die Aufmerksamkeit
esion
.
-
Hi,
ich bin gerade dabei, eine Authentifizierung via LDAP in meine WebApp einzubauen. Das ganze funktioniert auch schon ganz gut: Melde ich mich mit den falschen Daten (user/pass) an, so bekomme ich nach 3 Versuchen einen Error 401 (Unauthorized) - genau so soll es ja sein. Melde ich mich hingegen mit den richtigen Daten an, so bekomme ich einen Error 403 (Forbidden), was mir auch klar ist, da ich in LDAP keinerlei Rollen zugeteilt bin (also genau das gleiche wie weiter oben im Thread von scuffy geschildert).
Mein Problem: Ich kann in LDAP keine Rollen einpflegen (ca. 100.000 User => hier darf nicht jeder "rumpfuschen"). Deshalb möchte ich gerne nur die Authentifizierung (user/pass) via LDAP machen. Die Rollenzuweisung würde ich hingegen gerne in der web.xml machen.
Konkret stelle ich mir das in etwa so vor (willkürliche Syntax):
<user ldapmatch="(cn=hansi)||(cn=alfons)" role="admin" />
<user ldapmatch="ou=it,dc=de,dc=example,dc=com" role="readonly" />
Kann mir jemand sagen, ob dies möglich ist, oder müssen die Rollen unbedingt in LDAP definiert werden? (was meiner Meinung nach unsinnig wäre, da sich die Rollen ja von Webapp zu Webapp unterscheiden können)
Vielen Dank schonmal für eure Hilfe!
Viele Grüße
Markus
-
-
Hat denn keiner eine Idee dazu?
-
@ Makus
> die Rollen ja von Webapp zu Webapp unterscheiden können)
Wenn man es "richtig" macht hat jede webapp einen eigenen WEB-INF Ordner. Die Rollen für die jeweilige webseite können sich also unterscheiden.
Mit LDAP habe ich mich bis jetzt nicht beschäftigt. Sorry
esion
.
-
@Andron
ich knabber immer noch an einer Lösung.
Hast Du es hinbekommen, kennst Du ein workaround?
Bitte lass es mich wissen.
Grüsse esion
.
-
@esion
Jede meiner Apps hat ein eigenes WEB-INF Verzeichnis... Das ist auch nicht mein Problem.
Mein Problem ist viel mehr, dass ich ein Mapping zwischen LDAP-Inhalten und Webapp-Rollen benötige... Und dieses Mapping möchte ich für jede Webapp separat in deren web.xml machen.
Bsp:
- Rolle "Antragsteller" setzt sich aus allen Usern mit Gruppe "IT" && Country "DE" zusammen. Ausgeschlossen ist aber der User cn=gustl
- Rolle "Genehmiger" setzt sich aus den Usern mit cn=hansi, cn=fritzi und cn=horsti zusammen.
...
In meiner Webapp (JSF/MyFaces) möchte ich dann nur noch sagen:
Code :1 2 3
<h:commandButton action="..." value="genehmigen" rendered="#{securityContext.ifGranted['Genehmiger']}" />
In meiner aktuellen Konfiguration würde ich es so zum Laufen bekommen:
Code :1 2 3
<h:commandButton action="..." value="genehmigen" rendered="#{securityContext.ifAnyGranted['hansi','fritzi','horsti']}" />
Da ich aber an vielen Stellen Rollenabfragen habe, müsste ich überall die Benutzer auflisten, was inakzeptabel ist. Außerdem kann ich nur auf LDAP-Usernamen und LDAP-Gruppen zugreifen. Ich könnte z.B. keine Abfrage auf die LDAP-Location machen...
Hat jmd noch eine Idee?
Gruß
Markus
PS: Ich vermute dass das ganze darauf hinausläuft, dass ich mir eine eigene Realm-Klasse schreiben muss
Geändert von gloomer (15.06.07 um 16:04 Uhr)
-
Hi Markus habe leider noch nicht ganz verstanden.
Algemeine Frage: Wie viele Rollen hast Du im insgesamt und wie oft ändern sie sich?
Grundsätzlich: Wenn es zu viele Rollen werden halte ich es für
ungeschickt wenn sie Statisch in der web.xml liegen bzw es kein
UI gibt mit der sie geändert werden können.
Habe ich dich richtig verstanden? Mir sind die Enditäten nicht ganz klar.
IT | DE -> antragsteller access
Admin | DE -> antragsteller access
gusti | DE -> antragsteller denied
Quelle web.xml? - Rolle "Antragsteller" setzt sich aus allen Usern mit Gruppe "IT"
&& Country "DE" zusammen. Ausgeschlossen ist aber der User cn=gustl
gustel gehört weder zu antragsteller & genehmiger?
IT DE | hansi -> genehmiger denied
IT DE | frizi -> genehmiger denied
IT DE | horsti -> genehmiger denied
Quelle LDAP? - Rolle "Genehmiger" setzt sich aus den Usern mit cn=hansi, cn=fritzi und cn=horsti zusammen.
Sind alle Genemiger auch Antragsteller? (Teilmenge von Antragsteller)
'hansi','fritzi','horsti','markus','esion'
Die hier haben die sich doch schon angemeldet bevor sie auf die
Genemiger funktion zugreifen dürfen oder ?
Was ist bereits bekannt bevor der commandButton gerändert/nicht gerändert werden soll.
Der Name und dessen (Antragsteller)Rolle von zb hansi ist doch dann bekannt.
Kannst Du nicht vor die Genemiger Seite eine zweite realm Abfrage schalten
ob er auch zur Guppe Genehmiger gehört?
Und jetzt das eigendliche Problem Du kannst von dem XML realm nicht auf
LDAP schalten. Hast du schon versucht zwei Realms in der server.xml Einzutragen?
Was passiert dann?
Falls Dir die methoden zum abfragen von des aktuellen authentifizierete users nicht bekannt sein sollten.
javax.faces.contex
isUserInRole() //liefert true wenn die aktuelle authentifizierete Benutzer entsprechende rolle hat
getRemoteUser() //liefert den Name
getUSerPrincipal() // liefert java.security.Principal-Objekt.
zb methode
public boolean isUserInThisRole(String genehmiger){
ExternalContext ec = FacesContext.getCorrentInstance().getExternalContext();
return ec.isUserInRole(genehmiger);
}
Das Tomahawk Packet kennt noch visibleOnUserRol, enabledOnUserRole.
Grüsse esion
PS da kann noch der ein und der andere Tippfehler enthalten sein bin ein REALM und JSF .
Ähnliche Themen
-
Moderner Login-Mechanismus?
Von Trash im Forum PHPAntworten: 3Letzter Beitrag: 16.12.10, 11:10 -
Tomcat Login + Eclipse
Von Spechter im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 2Letzter Beitrag: 02.12.08, 12:38 -
JSP Tomcat Login
Von lexz im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 1Letzter Beitrag: 30.07.08, 16:40 -
Tomcat - Login
Von Kingbuddha im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 1Letzter Beitrag: 31.08.07, 15:49 -
Tomcat-Login-Daten weitergeben
Von mwflipper im Forum Enterprise Java (JEE, J2EE, Spring & Co.)Antworten: 0Letzter Beitrag: 03.01.07, 15:16



1Danke


Zitieren
Login





