tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Holman <>
Subject Re: {PATCH] Enhanced JNDI realm
Date Sun, 03 Mar 2002 13:03:48 GMT
At 20:11 01/03/02, Jonathan Eric Miller wrote

>Hi John,
>I'm glad to see that you have come up with a patch for JNDIRealm which
>allows users to be authenticated by a bind instead of having to query for a
>One thing that I'm wondering about though, with regard to your
>implementation, do you have to use groups? Or, can you specify a filter in
>order to determine which users are authorized? The reason why I'm curious is
>that I want to use JNDIRealm against our University-wide LDAP server.
>However, I don't have the ability to create groups in the directory. It
>would be nice if you could just specify a filter.

Yes, the patch lets you specify an arbitrary search filter to locate users 
in the directory, so it would be
possible to limit authentication (and therefore authorization) that way 
provided the criteria you want to filter on are already present
in the directory.

In addition, if you want to authorize through roles, a new "userRoleName" 
parameter can be used to define an attribute of the user that contains role 
name(s). These will be used in addition to any roles found by searching for 
explicit role entries (e.g. represented as groups).

In fact, you don't *have* to use groups to represent roles even in the 
existing implementation (the new parameter mostly just makes that more 
explicit).  For example suppose you wanted to limit access to people within 
a particular department. If people have an "ou" attribute whose value is 
the name of their department, you could arrange for them to have a role 
that is the name of their department by setting roleBase to the entry 
containing the users, roleSearch to "(&(uid = {1})"), and roleName to "ou".

>Also, would it be possible to integrate SSL/TLS support in as well?

I'm hoping to do that - but waiting to see whether my patch will be 
committed. It should be easy to support, but I don't actually have a 
directory server set up to test it at present.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message