Carsten
LDAP authentication with a bind is supported in the JNDIRealm included
with Tomcat 4.1
John.
Carsten Burghardt wrote:
Hi,
I tried to get a ldap-authentification with domino but noticed that the
current code (I checked tomcat 4.0.6 so if this is obsolete in a newer
version forgive m
Amy Roh wrote:
> I just committed fixes to validate only className and connectionURL and also to
> check either userPattern or userSearch is specified but not both.
Thanks!
> I don't think any change to JNDIRealm is necessary since I changed admin so that
> it doesn't replace null values with "
Amy
Yes - much too strict for JNDIRealm! The only configuration attributes
that should always be specified for this realm are className and
connectionURL. In addition either userPattern or userSearch must be
specified (but not both). Other attributes either have default values,
or not specify
The Tomcat 4.1 documents referenced on the index.html page are not up to
date (e.g. jndi-datasource-examples-howto, realm-howto).
John.
[EMAIL PROTECTED] wrote:
> remm2002/08/11 08:35:27
>
> Modified:docs index.html
>xdocsindex.xml
> Log:
> - Update s
Bug 11210 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11210) is a
security problem which could have serious effects for people using
JNDIRealm with the Netscape/iPlanet JNDI LDAP provider
(com.netscape.jndi.ldap.LdapContextFactory). The default provider
(com.sun.jndi.ldap.LdapCtxFactor
Sean
JNDIRealm in 4.1 does include an option to search the directory for the
user's entry, very much along the lines you suggest (except the
directory connection is persistent). Unfortunately much of the
documentation has still not been updated so this is less than obvious - and
the spec proba
Remy
I wrote the original JNDIRealm which Craig committed with modifications,
made major enhancements in March this year and submitted documentation
updates a couple of times since (which have still not been committed).
I'm prepared to maintain this component, but the difficulty of finding
an
I submitted some major changes to the JNDI Realm earlier this year, which
Craig committed in March. I also sent updates for the realm how-to and
realm configuration docs to this list shortly afterwards, but those have
not yet been committed. The current how-to doc in particular does not cover
;
> John, thanks for your patience with me on getting this patch committed!
> Could you also make sure that I got the facts right on my edits to the
> configuration docs? (A patch to tomcat-docs/realm-howto.xml to explain
> the new options would also be cool.)
Craig,
At 18:37 15/03/02, you wrote:
> John, thanks for your patience with me on getting this patch committed!
> Could you also make sure that I got the facts right on my edits to the
> configuration docs? (A patch to tomcat-docs/realm-howto.xml to explain
> the new options would also be
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
>password.
>
>One thing that I'm wondering about though, with regard to your
>implementati
Craig
I've attached a patch to enhance the current JNDI realm implementation.
This includes three features that have been requested a number of times and
appear in the draft functional specification:
** the realm can authenticate by binding to the directory as the user. This
mode of operation
BTW if you want to take a look at the native ldap realm
>module you
>can grab it from my web site. http://www.dahbura.com/ldap I thought if folks
>liked it and wanted to use it we could include it in the base build for
>tomcat.
>
>Should I just take the current snapshot in t
now, there is no standard attribute for this
purpose, so the user would have the extend the directory schema to
accommodate it, which might be a deterrant to some.
John.
>Tony
>
>
>John Holman wrote:
>
> > Craig
> >
> > I understand (and prefer!) the &quo
Craig
I've attached a revised version of your proposed functional specification
for JNDIRealm. The main changes are to spell out in more detail options for
determining the user's distinguished name, and expanding on the
functionality of the User Login mode. I've not said much about determining
ministrator sets things up to allow this.
>That should let us improve overall performance -- at least on the "log in
>with the system username/password" mode that we currently support.
>
>Craig
>
>
>On Tue, 8 Jan 2002, John Holman wrote:
>
> > Date: Tue, 08
Craig
After a long delay, I'm looking at your proposed functional spec for the
Tomcat 4 JNDI Realm, and am having trouble with this excerpt from the
"Adminstrator Login Mode Functionality" section:
> The following approaches should be supported [ for retrieving the roles
associated with an a
ny of the
>points of what I was looking at doing. I agree for many folks the JNDI
>implementation can suit much of their needs, I have just run across some
>folks that
>wanted better support for more diverse network environments.
I'd be happy to cooperate on this.
>L
At 04:28 04/01/02, Tony Dahbura wrote:
>I would like to see about proposing the development of an additional realm
>module for tomcat. I have begun some design on this and think it will
>meet the
>needs of many folks out there utilizing LDAP. I would like to propose a
>native
>LDAP realm modul
Casey
Unless I misunderstand, I think the existing JNDIRealm will handle this. In
the roleSearch parameter, {1} is substituted by the username, so in your
example you could have
roleBase= [ basedn for user entries ]
roleName="memberof"
roleSearch = "(uid={1})"
This might involve an additional d
you imagine making people type in X.500-style user names
>
>Martin
>Torgeir Veimo wrote:
>
> > John Holman wrote:
> > >
> > > As said before I'd like to add the ability to search the directory
> for the
> > > user's dn to cover cases
I was planning to fail authentication if more than one entry is found.
At 09:58 16/05/01, you wrote:
>John Holman wrote:
> >
> > As said before I'd like to add the ability to search the directory for the
> > user's dn to cover cases when a fixed pattern will not
en it
>will only fail under load. Usually in some horrible manner that will be
>difficult to trace back to the root cause.
Yes. The initial code makes no attempt at performance - it serialises all
requests through a single directory context.
John
> > -Original Message-
&
Here is a patch for the JNDI realm in Catalina that supports authentication
by binding to the directory with the credentials specified by the user.
I've added a configuration parameter "bindAsUser" which defaults to "true".
If set to "false" the realm authenticates as before: ie it retrieves the
to the
> > directory with the resultant DN and the user-entered password to
> > authenticate. This might be a little less efficient than
> > just searching and
> > getting the password as well, but is more secure than having the root
> > password to the ldap serv
> I preferred binding to the directory with supplied credentials because it
> allows the realm implementation to use an anonymous password for the rest
of
> what it needs.
Yes - I think binding is the better approach in general. Also the directory
can then contain password hashes rather than plai
The current JNDI realm implementation in Tomcat 4 is based on code I
submitted, which was subsequently modified and committed by Craig.
Two significant changes he made are:
- the original code found the DN of the user by searching the directory. The
current implementation, like Ellen Lockhart's
The log of Craig's initial commit for JNDIRealm says:
> TODO: Support an operational mode where the Realm attempts to bind to the
> directory server using the user's username and password (instead of a
> system administrator username and password). This is a different enough
> style that it pro
- Original Message -
From: "Martin Smith" <[EMAIL PROTECTED]>
> I wonder if it wouldn't be useful to permit a principal or a credential to
be an
> attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
> types of data, I wonder if it may be more efficient to mai
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> To authenticate the
> > user, the directory is first searched for an entry with an attribute
> > matching the given username. An attempt is then made to bind to the
> > directory using the name of that entry and the
One of the action items in the Catalina status document is a JNDI realm.
I've been working on this recently and wonder whether what I've done would
be useful to the project - though I'm not sure how best to get involved.
Incidentally, the status document lists James W as a volunteer for this
item.
I'm a user and I rightly don't get a vote
(and might do better to keep quiet!) but I think releasing a version 3.3 would be bad for the project unless the
concerns about support can be fully resolved. This is so even though it seems to be agreed that the basic code itself
is technically supe
32 matches
Mail list logo
