On 24/04/11 08:50, Jim Willeke wrote:
We are using Container Authentication and Authorization with JspWiki and
LDAP.
http://ldapwiki.willeke.com/wiki/TomcatAndLDAP
-jim
Jim Willeke
On Sat, Apr 23, 2011 at 8:20 PM, jlist9<[email protected]> wrote:
I found this page in my searching for a way to authenticate against OpenDS
LDAP
server. This is the page I found:
http://www.jspwiki.org/wiki/LDAPAuthentication?version=25
However I'm still confused after reading it. I'm using the latest version
of
jspwiki.
Is there an official or semi-official way of authenticating against a LDAP
server?
Thanks,
Jack
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
