 Vorherige |
 Hoch |
 Suche |
 Nächste |
Öffnen Sie die Datei tomcat/conf/server.xml und kommentieren Sie den normalen Realm mit userdatabase aus.
<!--
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>
-->
Fügen Sie statt dessen einen JNDI-Realm für LDAP nach folgendem Beispiel hinzu:
<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="0"
connectionName="cn=Manager,dc=hostname,dc=de"
connectionPassword="secret"
connectionURL="ldap://hostname.de:389"
userSearch="(uid={0})"
userPassword="userPassword"
userPattern="uid={0},ou=people,dc=hostname,dc=de"
roleBase="dc=roles,dc=hostname,dc=de"
roleName="cn"
roleSearch="(uniqueMember={0})"
roleSubtree="false"
/>
entweder userPattern oder userBase etc (s.u. Freiburg)
Bei diesem Beispiel wird davon ausgegangen, dass die User unter dem Knoten ou=people,dc=hostname,dc=de hängen, für die Userkennung uid benutzt wird (könnte stattdessen auch cn oder etwas anderes sein) und das Passwort im Attribut userPassword hinterlegt ist. Vergleiche folgende ldif-Einträge:
#der Hauptknoten
dn: dc =hostname, dc =de
dc : dc =hostname, dc =de
objectClass : dcObject
objectClass : organization
o : Hochschule XY
#Unterknoten people
dn: ou =people, dc =hostname, dc =de
ou : people
objectClass : top
objectClass : organizationalUnit
#User admin unter people,hostname,de
dn: uid =admin, ou =people, dc =hostname, dc =de
mail : admin@hochschuleXY.de
userPassword :: YWRtaW5wYXNzd29yZA= =
uid : admin
givenName : Admin
objectClass : person
objectClass : inetOrgPerson
sn : Admin
cn : Admin
#User testuser unter people,hostname,de
dn: uid =testuser, ou =people, dc =hostname, dc =de
userPassword :: YW5mYW5nMTI=
uid : testuser
givenName : test
objectClass : person
objectClass : inetOrgPerson
sn : test
cn : test
Passen Sie die Einträge userSearch , userPassword und userPattern ggfs. gemäß Ihren LDAP-Konventionen an (wenn das Passwort nicht in einem Attribut abgelegt ist, kann die Angabe u.U. auch entfallen).
Alle User, die Sie durch diese Parameter gefunden werden, können sich bei Tomcat als User authentifizieren – was aber nicht heißt, dass auch alle User Zugriff auf SuperX bekommen.
Als nächstes muss geklärt werden, welche Gruppen/Rollen Zugriff auf SuperX bekommen sollen.
Die Gruppenzugehörigkeit der User wird aus LDAP über die Parameter roleBase,roleName und RoleSearch herausgesucht.
In unserem Beispiel ist in LDAP ein Knoten dc=roles,dc=hostname,dc=de angelegt unter dem eine Gruppe sxusers mit den eindeutigen Kennzeichern der Gruppenmitglieder existiert.
Vergleiche folgende Ldif-Einträge
#Knoten roles unter dem Haupt
dn: dc =roles, dc =hostname, dc =de
objectClass : person
sn : Roles Entry
cn : roles
#Gruppe sxusers unter role
dn: cn =sxusers, dc =roles, dc =hostname, dc =de
objectClass : groupOfUniqueNames
uniqueMember : uid =admin, ou =people, dc =hostname, dc =de
uniqueMember : uid =testuser, ou =people, dc =hostname, dc =de
cn : sxusers
Bei der Realmdefinition muss angegeben werden, wie nach Gruppenzugehörigkeit gesucht werden soll, im Beispiel ist die Basis der Knoten roles , der Name der Rolle steht in cn und die Mitglieder werden über uniqueMember identifiziert. So erklären sich die folgenden Einträge in der Realmdefinition:
roleBase="dc=roles,dc=hostname,dc=de"
roleName="cn"
roleSearch="(uniqueMember={0})"
Es ist nicht unbedingt nötig, eine Gruppe sxusers zu haben. Welche Gruppen Zugriff auf SuperX haben sollen, wird in der Datei tomcat/webapps/superx/WEB-INF/web.xml geregelt.
Öffnen Sie die Datei und fügen Sie den folgenden Abschnitt nach am Ende ein:
<security-constraint>
<display-name> SuperX Security Constraint </display-name>
<web-resource-collection>
<web-resource-name> Protected Area </web-resource-name>
<url-pattern> /* </url-pattern>
<!-- root ist hier schon IP:8080/superx, also ohne /superx angeben-->
<!-- z.B. /FH_TEST1/* für Unterverzeichnis eines Mandanten-->
<http-method> DELETE </http-method>
<http-method> GET </http-method>
<http-method> POST </http-method>
<http-method> PUT </http-method>
</web-resource-collection>
<auth-constraint>
<role-name> sxusers </role-name>
</auth-constraint>
</security-constraint>
<login-config>
<realm-name> SuperX Authentication Area </realm-name>
<auth-method> FORM </auth-method>
<form-login-config>
<form-login-page> /anmeldung_ldap.jsp </form-login-page>
<form-error-page> /anmeldung_jail.jsp </form-error-page>
<!-- Datei also unter webapps/superx/anmeldung_ldap.jsp-->
</form-login-config>
</login-config>
<security-role>
<role-name> sxusers </role-name>
</security-role>
Achtung: Wenn Sie auch Joolap einsetzen, darf das joolap-Unterverzeichnis nicht geschützt sein, schützen Sie in dem Fall am besten per url-pattern nur die Unterverzeichnisse applet,servlet,edit und xml.
Für jede Grupppe, die Zugriff auf SuperX erhalten soll machen Sie einen Eintrag
<role-name>Gruppenname</role-name> unter <auth-constraint> und <security-role> .
Wenn Sie keine spezielle LDAP-Usergruppe haben, können Sie als role-name auch * angeben.
Benennen Sie die mitgelieferten Dateien webapps/superx/anmeldung_ldap.jsp.sam und anmeldung_jail.jsp.sam um nach anmeldung_ldap.jsp und anmeldung_jail.jsp und gestalten Sie sie ggfs. nach Ihren Vorstellungen.
Hilfreiche Links
http://tomcat.apache.org/tomcat-4.0-doc/realm-howto.html
http://cymulacrum.net/writings/adv_tomcat/c302.html
http://cymulacrum.net/writings/adv_tomcat/c487.html
Startdateien anpassen
a) superx/
Löschen Sie die index.htm und index.jsp und benennen Sie die Datei index.jsp.sam um in index.jsp
b) superx/applet
Löschen Sie alle alten Startdateien wie index.htm, superx.html, index.jsp und benennen Sie die index.jsp.sam um nach index.jsp. Falls Sie ein mandantenfähiges SuperX laufen lassen, ändern Sie in der Datei den Parameter MandantenID von default auf die ID des jeweiligen Mandanten.
c) superx/xml
Löschen Sie auch hier alle vorhandenen Startdateien wie index.htm,index2.htm, index.jsp,anmeldung.htm,anmeldung.js,anmeldung.jsp.
Benennen Sie dann index.htm.sam um in index.htm, anmeldung.jsp.sam in anmeldung.jsp (darin auch wieder ggfs. den Parameter
MandantenID anpassen)
Die index.html muss im Frame auf anmeldung.jsp verweisen.
1 Abmeldeurl kontrollieren
Standardmäßig wird bei der Abmeldung vom XML-Frontend auf die Url /superx/ redirected, falls eine andere URL gewünscht ist, kann diese als Parameter alt_redirect_url dem SuperXmlAbmeldung-Servlet in der web.xml übergeben werden.
 |
|  |
Seite 98 / 387 Letzter Update: 26.6.2019 Impressum| Datenschutz |