incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jlist9 <>
Subject Re: LDAP Authentication?
Date Sun, 24 Apr 2011 16:23:26 GMT

Thanks a lot for the instructions! I'm not familiar with container
security so the list looks somewhat daunting to me :-)

I was also looking at JForum's code - it does LDAP authentication.
I suppose its security mechanism isn't implemented the same way
as it uses some internal simple classes to verify user information
via JNDI. Is it possible to implement something like this in jspwiki
without having to do a lot of modifications?


On Sun, Apr 24, 2011 at 2:50 AM, Brian Burch <> wrote:

> I can confirm that all the documentation exists, yet it can be hard to
> follow and integrate, even if you believe you understand ldap AND container
> security! What I have works well and scales, but might not be perfect.
> 1. You need to set up your ldap directory for webapp users:
> 1.1. Define an attribute to hold the various container security classes
> that you want. I couldn't find anything pre-defined that suited me, so I
> created a new attribute called "tomcatRole" in a "spare" section of the
> schema oid space.
> 1.2. I then defined a new objectClass that would permit user entries to
> have tomcatRole attributes, in my case called "tomcatRoleAllowed".
> 1.3. I then modified my user entries to add the tomcatRoleAllowed
> objectclass and appropriate tomcatRole attributes (e.e. wikiUser,
> webMailUser, manager, etc).
> At this point, you have a Authentication/Authorisation dataset in the ldap
> directory, but nothing is using it.
> 2. You need to set up your ldap directory so that your web server can
> authenticate users against the ldap directory:
> 2.1. If you don't have one already, set up ACI's and a group that has
> permission to read "secure" attributes, such as password hashes and the new
> container role.
> 2.2. define a new authenticator user entry for tomcat and put it into the
> group.
> At this point, you should be able to test the new authenticator credentials
> by searching for a user entry and retrieving the password hash and the
> associated web container authorisations.
> 3. Turn on tomcat container security:
> 3.1. Modify the tomcat conf/server.xml inside the <engine> to define a
> JNDIRealm which specifies the ldap directory server and your authenticator's
> credentials, how to search for user entries and which (protected) attributes
> to retrieve.
> 3.2. Within the Host entry, define the SingleSignOn Valve so that someone
> authenticating with any webapp will not need to signon again when going to a
> different webapp container.
> At this point, tomcat will force users that wish to access a protected
> webapp to signon (if they haven't already done so), authenticating them
> against your ldap directory and discovering the roles they have been
> assigned. The webapps only know the names of the roles - not how they are
> stored or assigned.
> 4. Configure jspwiki to use container security:
> 4.1. turn on the commented-out section in wiki/WEB-INF/web.xml and modify
> it to suit your requirements. My jspwiki has several security constraints:
> the entire container is protected; guests can only read; some users can
> create new entries; managers can delete. It is tricky to define exactly
> which resources need to be protected at the different levels, but it isn't
> too confusing because you are only working with a few abstract role names. I
> had to do a lot of testing to fine tune my web-resource-collections before I
> was satisfied.
> At this point, your other webapps would not be protected. My own system has
> only the home and standard error pages unprotected, so I had to setup a
> single signon and menu webapp that forces all users to authenticate. I also
> had to modify each of my other webapps to enforce container security.
> It is a lot to do, but it will work in the end. If you follow the sequence
> of tasks above, you should have confidence that each step is correct and so
> need only worry about one thing at a time!
> Good luck,
> Brian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message