You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Shelly <sw...@yahoo.com> on 2002/01/04 03:47:36 UTC
Problem with JNDIRealm ...
Hello,
I'm running Tomcat 4 on Unix and trying to use JNDIRealm for
authentication.
I use Netscape DAP server, and the hierarchy of entries in the directory
is
o=My Company
|
+---------------+---------------+
| | |
ou=People ou=Groups ...
|
+-------+-------+
| |
ou=Employee ...
|
+-----+-----+
| | |
enum=001 ... enum=111
However, the logic attribute is uid.
When I do a search for a valid uid, it returns null.
If I use DirContext.listBindings("") to get name-to-objects, no object
returns; (Please see code below).
If I use DirContext.listBindings("o=My Company") to get name-to-objects,
it returns (Name: ClassName: Object):
ou=Resources: com.sun.jndi.ldap.LdapCtx:
com.sun.jndi.ldap.LdapCtx@586fd3
ou=People: com.sun.jndi.ldap.LdapCtx: com.sun.jndi.ldap.LdapCtx@586jhk
...
Hash table en = new Hash table();
env.put(Context.INITIAL_CONTEXT_FACTORY, context Factory);
if (connection Name != null)
env.put(Context.SECURITY_PRINCIPAL, connection Name);
if (connection Password != null)
env.put(Context.SECURITY_CREDENTIALS, connection Password);
if (connection URL != null)
env.put(Context.PROVIDER_URL, connection URL);
context = new InitialDirContext(env);
try {
// Get listing of context
Naming Enumeration bindings = context.listBindings("");
// Go through each item in list
while (bindings.hasMore()) {
Binding bd = (Binding)bindings.next();
log(bd.getName() + ": " + bd.getClassName() + ": " +
bd.getObject());
}
} catch (Naming Exception e) {
log("List Bindings failed: " + e);
}
If I bind dn."", I got "HTTP Status 500 - Internal Server Error" message
when I access the secured page.
I'm wondering if anyone knows the answers to any of the following
questions:
1. How to get a dn from uid when uid is not part of the dn?
2. Does SHA digest been supported? When DAP server use SHA digest for
userPassword, how do I encrypt SHA digest?
3. How to use an anonymous password for binding instead of using
connectionName/connectionPassword?
Thanks
Shelly
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by Tony Dahbura <to...@dahbura.com>.
John:
It was all I could do to get the code posted!! I need to put the source code up as
well-will get to it this week. I think it covers the features of your original
proposal. How should we work on getting both of them admitted and beefing up the
realm services. I am not an expert on working on projects like this-more of a
developer.
I would like to take a stab at adding the functionality to the JNDIRealm module as
well. I have always believed if users have multiple choices for things they will
pick the one that works for them in their environment.
Should I just start working on it? Do you want to work on it together?
Let me know how we should proceed,
Tony
John Holman wrote:
> Tony
>
> I had a look at the documentation for your LDAPRealm and apart from the HA
> features it looks very similar to my original JNDIRealm proposal both in
> features and configuration options. I couldn't see any source code on your
> site though.
>
> I sent a revised functional specification to the tomcat-dev list a few
> weeks ago elaborating on what I think are the most important features
> (mostly authentication via simple bind and searching for the user's entry
> when necessary) but got no response. I'd like to see those features in
> JNDIRealm one way or the other but don't know how to make progress with
> getting it accepted.
>
> John.
>
> At 03:52 26/01/02, you wrote:
> >John:
> >Sorry I have been really busy and have not had a chance to followup on my
> >emails.
> >The original author of the sdk is actually back doing continuing work on
> >it. Yes
> >indeed you can replace the ldap provider with the one from iplanet and it
> >gets you
> >much better session and connection recovery.
> >
> >I actually spent a bit of time working on a native ldap implementation,
> >not using
> >jndi, and put in conn pooling and other features. I think I would like to
> >look at
> >rolling these into the base line jndi implementation as well and leave
> >folks with
> >an option to choose either realm implementation they would like to use
> >with tomcat.
> >
> >How about I pick up the jndi module and work on it a bit to get some of these
> >features in. 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 there and work on it or does it
> >need to
> >be checked out?
> >
> >Tony
> >
> >
> >John Holman wrote:
> >
> > > At 21:41 04/01/02, Tony Dahbura wrote:
> > > >John:
> > > >There are other issues with the JNDI implementation that we have run into
> > > >with some
> > > >commercial high end load balancers. It has to do with connection
> > > >re-authentication
> > > >and sessions getting dropped on non used connections.
> > > > I did some work on the actual
> > > >API for the Netscape LDAP implementation and we puti n handling of this
> > > >situation
> > > >as well. It really from a programmer perspective looks the same but
> > > >handles a lot
> > > >of low level details with regards to server connections that work better
> > > >in a many
> > > >HA settings.
> > >
> > > Our own requirements are quite modest and this has not been a problem so
> > > far. However I'm sure others would benefit from a robust and high
> > > performing implementation.
> > >
> > > I know little about the Netscape Directory SDK, but was under the
> > > impression that the API it offers to programmers for access to directory
> > > services is very different to JNDI. However, looking at the Mozilla site
> > > today I noticed that an LDAP provider for JNDI is included in version 4.1
> > > of the SDK. Were you perhaps contemplating using JNDI with this Netscape
> > > LDAP provider rather than the Netscape LDAP API itself? If so, does the
> > > Netscape LDAP provider for JNDI have advantages over Sun's version (other
> > > than being open source of course) and are there still active developers?
> > > (My impression was that there has been little activity over the last year).
> > >
> > > My feeling initially is that if we can work around any disadvantages it
> > > would be best to stay with the JNDI API to directory services but allow for
> > > a choice of LDAP providers.
> > >
> > > >I would love to work with you on the proposal for this. As I have
> > indicated I
> > > >started a wish list of things to code in this realm module you hit
> > many 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.
> > >
> > > >Let's flesh this out and see what comes from it.
> > > >
> > > >Tony
> > > >
> > > >
> > > >John Holman wrote:
> > > >
> > > > > 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 module that allows utlization of ldap features that may
> > or may
> > > > > >not be
> > > > > >possible through the JNDI layer.
> > > > >
> > > > > As far as I can see, writing a "native LDAP realm module" - if by
> > that you
> > > > > mean using the API provided by the Netscape directory SDK rather
> > than Sun's
> > > > > JNDI API - would make little difference to the functionality possible.
> > > > > There may be performance benefits, though I have read conflicting
> > reports
> > > > > on that.
> > > > >
> > > > > >The items I am looking at designing into this module are:
> > > > > >1-Connection pooling to support high performance access
> > > > > >2-HA capabilities to support failover if a server goes away
> > > > > >3-Authentication via the server rather than comparison of the
> > passwords in
> > > > > >digested forms (this option will also be supported)
> > > > > >4-support for other realm group models (still checking into this).
> > > > > >5-User location without DN identification (no need to be able to
> > build the
> > > > > >DN to
> > > > > >find the user)
> > > > > >6-SSL support for communications
> > > > >
> > > > > Some history ...
> > > > >
> > > > > The current JNDIRealm implementation in Tomcat 4 is based on code I
> > > > > proposed back in April last year. I believe the existing
> > implementation is
> > > > > sufficiently flexible to cover most ways of representing group
> > information
> > > > > in the directory (item 4), and adding SSL support (item 6) should be
> > > > > trivial. However item 3 (authentication by binding to the directory
> > as the
> > > > > user rather than by retrieving credentials and comparing them
> > explicitly in
> > > > > the realm) and feature 5 (essentially, finding the user's DN by
> > searching
> > > > > the directory on an arbitrary attribute) are not included. I think
> > items 3
> > > > > and 5 are essential if the module is to be of much practical use.
> > > > >
> > > > > In fact my original proposal did include much of the missing
> > functionality
> > > > > (though not the performance and availability enhancements you mention).
> > > > > Craig made several significant improvements to the code before
> > committing
> > > > > it, but also removed support for items 3 and 5. I subsequently
> > proposed a
> > > > > patch restoring item 3, and planned to propose a second patch restoring
> > > > > item 5 if the first patch was accepted. Craig's response was that
> > we should
> > > > > first get agreement on top-level goals, and proposed a functional
> > > > > specification for the JNDI Realm which is included in the Tomcat
> > release
> > > > > documentation. This spec includes two "login modes" which cover
> > item 3, but
> > > > > says little about the other items.
> > > > >
> > > > > As far as I know there has been no discussion of the spec since
> > then, and
> > > > > it still has proposed status. So perhaps the next step before
> > enhancing the
> > > > > existing module would be for the group to reach agreement about the
> > > > > required features and produce a revised spec. I'm afraid I never
> > got round
> > > > > to proposing changes to the spec myself but now the subject has come up
> > > > > again I will try to have a go at it. (I'll probably need to look at the
> > > > > format of the source document, which is in some dialect of xml).
> > > > >
> > > > > However, I don't know what the position would be about a completely new
> > > > module.
> > > > >
> > > > > Cheers, John.
> > > > >
> > > > > --
> > > > > To unsubscribe,
> > > > e-mail: <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > >--
> > > >To unsubscribe,
> > e-mail: <ma...@jakarta.apache.org>
> > > >For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe,
> > e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by John Holman <j....@qmul.ac.uk>.
Tony
I had a look at the documentation for your LDAPRealm and apart from the HA
features it looks very similar to my original JNDIRealm proposal both in
features and configuration options. I couldn't see any source code on your
site though.
I sent a revised functional specification to the tomcat-dev list a few
weeks ago elaborating on what I think are the most important features
(mostly authentication via simple bind and searching for the user's entry
when necessary) but got no response. I'd like to see those features in
JNDIRealm one way or the other but don't know how to make progress with
getting it accepted.
John.
At 03:52 26/01/02, you wrote:
>John:
>Sorry I have been really busy and have not had a chance to followup on my
>emails.
>The original author of the sdk is actually back doing continuing work on
>it. Yes
>indeed you can replace the ldap provider with the one from iplanet and it
>gets you
>much better session and connection recovery.
>
>I actually spent a bit of time working on a native ldap implementation,
>not using
>jndi, and put in conn pooling and other features. I think I would like to
>look at
>rolling these into the base line jndi implementation as well and leave
>folks with
>an option to choose either realm implementation they would like to use
>with tomcat.
>
>How about I pick up the jndi module and work on it a bit to get some of these
>features in. 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 there and work on it or does it
>need to
>be checked out?
>
>Tony
>
>
>John Holman wrote:
>
> > At 21:41 04/01/02, Tony Dahbura wrote:
> > >John:
> > >There are other issues with the JNDI implementation that we have run into
> > >with some
> > >commercial high end load balancers. It has to do with connection
> > >re-authentication
> > >and sessions getting dropped on non used connections.
> > > I did some work on the actual
> > >API for the Netscape LDAP implementation and we puti n handling of this
> > >situation
> > >as well. It really from a programmer perspective looks the same but
> > >handles a lot
> > >of low level details with regards to server connections that work better
> > >in a many
> > >HA settings.
> >
> > Our own requirements are quite modest and this has not been a problem so
> > far. However I'm sure others would benefit from a robust and high
> > performing implementation.
> >
> > I know little about the Netscape Directory SDK, but was under the
> > impression that the API it offers to programmers for access to directory
> > services is very different to JNDI. However, looking at the Mozilla site
> > today I noticed that an LDAP provider for JNDI is included in version 4.1
> > of the SDK. Were you perhaps contemplating using JNDI with this Netscape
> > LDAP provider rather than the Netscape LDAP API itself? If so, does the
> > Netscape LDAP provider for JNDI have advantages over Sun's version (other
> > than being open source of course) and are there still active developers?
> > (My impression was that there has been little activity over the last year).
> >
> > My feeling initially is that if we can work around any disadvantages it
> > would be best to stay with the JNDI API to directory services but allow for
> > a choice of LDAP providers.
> >
> > >I would love to work with you on the proposal for this. As I have
> indicated I
> > >started a wish list of things to code in this realm module you hit
> many 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.
> >
> > >Let's flesh this out and see what comes from it.
> > >
> > >Tony
> > >
> > >
> > >John Holman wrote:
> > >
> > > > 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 module that allows utlization of ldap features that may
> or may
> > > > >not be
> > > > >possible through the JNDI layer.
> > > >
> > > > As far as I can see, writing a "native LDAP realm module" - if by
> that you
> > > > mean using the API provided by the Netscape directory SDK rather
> than Sun's
> > > > JNDI API - would make little difference to the functionality possible.
> > > > There may be performance benefits, though I have read conflicting
> reports
> > > > on that.
> > > >
> > > > >The items I am looking at designing into this module are:
> > > > >1-Connection pooling to support high performance access
> > > > >2-HA capabilities to support failover if a server goes away
> > > > >3-Authentication via the server rather than comparison of the
> passwords in
> > > > >digested forms (this option will also be supported)
> > > > >4-support for other realm group models (still checking into this).
> > > > >5-User location without DN identification (no need to be able to
> build the
> > > > >DN to
> > > > >find the user)
> > > > >6-SSL support for communications
> > > >
> > > > Some history ...
> > > >
> > > > The current JNDIRealm implementation in Tomcat 4 is based on code I
> > > > proposed back in April last year. I believe the existing
> implementation is
> > > > sufficiently flexible to cover most ways of representing group
> information
> > > > in the directory (item 4), and adding SSL support (item 6) should be
> > > > trivial. However item 3 (authentication by binding to the directory
> as the
> > > > user rather than by retrieving credentials and comparing them
> explicitly in
> > > > the realm) and feature 5 (essentially, finding the user's DN by
> searching
> > > > the directory on an arbitrary attribute) are not included. I think
> items 3
> > > > and 5 are essential if the module is to be of much practical use.
> > > >
> > > > In fact my original proposal did include much of the missing
> functionality
> > > > (though not the performance and availability enhancements you mention).
> > > > Craig made several significant improvements to the code before
> committing
> > > > it, but also removed support for items 3 and 5. I subsequently
> proposed a
> > > > patch restoring item 3, and planned to propose a second patch restoring
> > > > item 5 if the first patch was accepted. Craig's response was that
> we should
> > > > first get agreement on top-level goals, and proposed a functional
> > > > specification for the JNDI Realm which is included in the Tomcat
> release
> > > > documentation. This spec includes two "login modes" which cover
> item 3, but
> > > > says little about the other items.
> > > >
> > > > As far as I know there has been no discussion of the spec since
> then, and
> > > > it still has proposed status. So perhaps the next step before
> enhancing the
> > > > existing module would be for the group to reach agreement about the
> > > > required features and produce a revised spec. I'm afraid I never
> got round
> > > > to proposing changes to the spec myself but now the subject has come up
> > > > again I will try to have a go at it. (I'll probably need to look at the
> > > > format of the source document, which is in some dialect of xml).
> > > >
> > > > However, I don't know what the position would be about a completely new
> > > module.
> > > >
> > > > Cheers, John.
> > > >
> > > > --
> > > > To unsubscribe,
> > > e-mail: <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > >--
> > >To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by Tony Dahbura <to...@dahbura.com>.
John:
Sorry I have been really busy and have not had a chance to followup on my emails.
The original author of the sdk is actually back doing continuing work on it. Yes
indeed you can replace the ldap provider with the one from iplanet and it gets you
much better session and connection recovery.
I actually spent a bit of time working on a native ldap implementation, not using
jndi, and put in conn pooling and other features. I think I would like to look at
rolling these into the base line jndi implementation as well and leave folks with
an option to choose either realm implementation they would like to use with tomcat.
How about I pick up the jndi module and work on it a bit to get some of these
features in. 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 there and work on it or does it need to
be checked out?
Tony
John Holman wrote:
> At 21:41 04/01/02, Tony Dahbura wrote:
> >John:
> >There are other issues with the JNDI implementation that we have run into
> >with some
> >commercial high end load balancers. It has to do with connection
> >re-authentication
> >and sessions getting dropped on non used connections.
> > I did some work on the actual
> >API for the Netscape LDAP implementation and we puti n handling of this
> >situation
> >as well. It really from a programmer perspective looks the same but
> >handles a lot
> >of low level details with regards to server connections that work better
> >in a many
> >HA settings.
>
> Our own requirements are quite modest and this has not been a problem so
> far. However I'm sure others would benefit from a robust and high
> performing implementation.
>
> I know little about the Netscape Directory SDK, but was under the
> impression that the API it offers to programmers for access to directory
> services is very different to JNDI. However, looking at the Mozilla site
> today I noticed that an LDAP provider for JNDI is included in version 4.1
> of the SDK. Were you perhaps contemplating using JNDI with this Netscape
> LDAP provider rather than the Netscape LDAP API itself? If so, does the
> Netscape LDAP provider for JNDI have advantages over Sun's version (other
> than being open source of course) and are there still active developers?
> (My impression was that there has been little activity over the last year).
>
> My feeling initially is that if we can work around any disadvantages it
> would be best to stay with the JNDI API to directory services but allow for
> a choice of LDAP providers.
>
> >I would love to work with you on the proposal for this. As I have indicated I
> >started a wish list of things to code in this realm module you hit many 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.
>
> >Let's flesh this out and see what comes from it.
> >
> >Tony
> >
> >
> >John Holman wrote:
> >
> > > 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 module that allows utlization of ldap features that may or may
> > > >not be
> > > >possible through the JNDI layer.
> > >
> > > As far as I can see, writing a "native LDAP realm module" - if by that you
> > > mean using the API provided by the Netscape directory SDK rather than Sun's
> > > JNDI API - would make little difference to the functionality possible.
> > > There may be performance benefits, though I have read conflicting reports
> > > on that.
> > >
> > > >The items I am looking at designing into this module are:
> > > >1-Connection pooling to support high performance access
> > > >2-HA capabilities to support failover if a server goes away
> > > >3-Authentication via the server rather than comparison of the passwords in
> > > >digested forms (this option will also be supported)
> > > >4-support for other realm group models (still checking into this).
> > > >5-User location without DN identification (no need to be able to build the
> > > >DN to
> > > >find the user)
> > > >6-SSL support for communications
> > >
> > > Some history ...
> > >
> > > The current JNDIRealm implementation in Tomcat 4 is based on code I
> > > proposed back in April last year. I believe the existing implementation is
> > > sufficiently flexible to cover most ways of representing group information
> > > in the directory (item 4), and adding SSL support (item 6) should be
> > > trivial. However item 3 (authentication by binding to the directory as the
> > > user rather than by retrieving credentials and comparing them explicitly in
> > > the realm) and feature 5 (essentially, finding the user's DN by searching
> > > the directory on an arbitrary attribute) are not included. I think items 3
> > > and 5 are essential if the module is to be of much practical use.
> > >
> > > In fact my original proposal did include much of the missing functionality
> > > (though not the performance and availability enhancements you mention).
> > > Craig made several significant improvements to the code before committing
> > > it, but also removed support for items 3 and 5. I subsequently proposed a
> > > patch restoring item 3, and planned to propose a second patch restoring
> > > item 5 if the first patch was accepted. Craig's response was that we should
> > > first get agreement on top-level goals, and proposed a functional
> > > specification for the JNDI Realm which is included in the Tomcat release
> > > documentation. This spec includes two "login modes" which cover item 3, but
> > > says little about the other items.
> > >
> > > As far as I know there has been no discussion of the spec since then, and
> > > it still has proposed status. So perhaps the next step before enhancing the
> > > existing module would be for the group to reach agreement about the
> > > required features and produce a revised spec. I'm afraid I never got round
> > > to proposing changes to the spec myself but now the subject has come up
> > > again I will try to have a go at it. (I'll probably need to look at the
> > > format of the source document, which is in some dialect of xml).
> > >
> > > However, I don't know what the position would be about a completely new
> > module.
> > >
> > > Cheers, John.
> > >
> > > --
> > > To unsubscribe,
> > e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by John Holman <j....@qmul.ac.uk>.
At 21:41 04/01/02, Tony Dahbura wrote:
>John:
>There are other issues with the JNDI implementation that we have run into
>with some
>commercial high end load balancers. It has to do with connection
>re-authentication
>and sessions getting dropped on non used connections.
> I did some work on the actual
>API for the Netscape LDAP implementation and we puti n handling of this
>situation
>as well. It really from a programmer perspective looks the same but
>handles a lot
>of low level details with regards to server connections that work better
>in a many
>HA settings.
Our own requirements are quite modest and this has not been a problem so
far. However I'm sure others would benefit from a robust and high
performing implementation.
I know little about the Netscape Directory SDK, but was under the
impression that the API it offers to programmers for access to directory
services is very different to JNDI. However, looking at the Mozilla site
today I noticed that an LDAP provider for JNDI is included in version 4.1
of the SDK. Were you perhaps contemplating using JNDI with this Netscape
LDAP provider rather than the Netscape LDAP API itself? If so, does the
Netscape LDAP provider for JNDI have advantages over Sun's version (other
than being open source of course) and are there still active developers?
(My impression was that there has been little activity over the last year).
My feeling initially is that if we can work around any disadvantages it
would be best to stay with the JNDI API to directory services but allow for
a choice of LDAP providers.
>I would love to work with you on the proposal for this. As I have indicated I
>started a wish list of things to code in this realm module you hit many 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.
>Let's flesh this out and see what comes from it.
>
>Tony
>
>
>John Holman wrote:
>
> > 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 module that allows utlization of ldap features that may or may
> > >not be
> > >possible through the JNDI layer.
> >
> > As far as I can see, writing a "native LDAP realm module" - if by that you
> > mean using the API provided by the Netscape directory SDK rather than Sun's
> > JNDI API - would make little difference to the functionality possible.
> > There may be performance benefits, though I have read conflicting reports
> > on that.
> >
> > >The items I am looking at designing into this module are:
> > >1-Connection pooling to support high performance access
> > >2-HA capabilities to support failover if a server goes away
> > >3-Authentication via the server rather than comparison of the passwords in
> > >digested forms (this option will also be supported)
> > >4-support for other realm group models (still checking into this).
> > >5-User location without DN identification (no need to be able to build the
> > >DN to
> > >find the user)
> > >6-SSL support for communications
> >
> > Some history ...
> >
> > The current JNDIRealm implementation in Tomcat 4 is based on code I
> > proposed back in April last year. I believe the existing implementation is
> > sufficiently flexible to cover most ways of representing group information
> > in the directory (item 4), and adding SSL support (item 6) should be
> > trivial. However item 3 (authentication by binding to the directory as the
> > user rather than by retrieving credentials and comparing them explicitly in
> > the realm) and feature 5 (essentially, finding the user's DN by searching
> > the directory on an arbitrary attribute) are not included. I think items 3
> > and 5 are essential if the module is to be of much practical use.
> >
> > In fact my original proposal did include much of the missing functionality
> > (though not the performance and availability enhancements you mention).
> > Craig made several significant improvements to the code before committing
> > it, but also removed support for items 3 and 5. I subsequently proposed a
> > patch restoring item 3, and planned to propose a second patch restoring
> > item 5 if the first patch was accepted. Craig's response was that we should
> > first get agreement on top-level goals, and proposed a functional
> > specification for the JNDI Realm which is included in the Tomcat release
> > documentation. This spec includes two "login modes" which cover item 3, but
> > says little about the other items.
> >
> > As far as I know there has been no discussion of the spec since then, and
> > it still has proposed status. So perhaps the next step before enhancing the
> > existing module would be for the group to reach agreement about the
> > required features and produce a revised spec. I'm afraid I never got round
> > to proposing changes to the spec myself but now the subject has come up
> > again I will try to have a go at it. (I'll probably need to look at the
> > format of the source document, which is in some dialect of xml).
> >
> > However, I don't know what the position would be about a completely new
> module.
> >
> > Cheers, John.
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by Tony Dahbura <to...@dahbura.com>.
John:
There are other issues with the JNDI implementation that we have run into with some
commercial high end load balancers. It has to do with connection re-authentication
and sessions getting dropped on non used connections. I did some work on the actual
API for the Netscape LDAP implementation and we puti n handling of this situation
as well. It really from a programmer perspective looks the same but handles a lot
of low level details with regards to server connections that work better in a many
HA settings.
I would love to work with you on the proposal for this. As I have indicated I
started a wish list of things to code in this realm module you hit many 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.
Let's flesh this out and see what comes from it.
Tony
John Holman wrote:
> 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 module that allows utlization of ldap features that may or may
> >not be
> >possible through the JNDI layer.
>
> As far as I can see, writing a "native LDAP realm module" - if by that you
> mean using the API provided by the Netscape directory SDK rather than Sun's
> JNDI API - would make little difference to the functionality possible.
> There may be performance benefits, though I have read conflicting reports
> on that.
>
> >The items I am looking at designing into this module are:
> >1-Connection pooling to support high performance access
> >2-HA capabilities to support failover if a server goes away
> >3-Authentication via the server rather than comparison of the passwords in
> >digested forms (this option will also be supported)
> >4-support for other realm group models (still checking into this).
> >5-User location without DN identification (no need to be able to build the
> >DN to
> >find the user)
> >6-SSL support for communications
>
> Some history ...
>
> The current JNDIRealm implementation in Tomcat 4 is based on code I
> proposed back in April last year. I believe the existing implementation is
> sufficiently flexible to cover most ways of representing group information
> in the directory (item 4), and adding SSL support (item 6) should be
> trivial. However item 3 (authentication by binding to the directory as the
> user rather than by retrieving credentials and comparing them explicitly in
> the realm) and feature 5 (essentially, finding the user's DN by searching
> the directory on an arbitrary attribute) are not included. I think items 3
> and 5 are essential if the module is to be of much practical use.
>
> In fact my original proposal did include much of the missing functionality
> (though not the performance and availability enhancements you mention).
> Craig made several significant improvements to the code before committing
> it, but also removed support for items 3 and 5. I subsequently proposed a
> patch restoring item 3, and planned to propose a second patch restoring
> item 5 if the first patch was accepted. Craig's response was that we should
> first get agreement on top-level goals, and proposed a functional
> specification for the JNDI Realm which is included in the Tomcat release
> documentation. This spec includes two "login modes" which cover item 3, but
> says little about the other items.
>
> As far as I know there has been no discussion of the spec since then, and
> it still has proposed status. So perhaps the next step before enhancing the
> existing module would be for the group to reach agreement about the
> required features and produce a revised spec. I'm afraid I never got round
> to proposing changes to the spec myself but now the subject has come up
> again I will try to have a go at it. (I'll probably need to look at the
> format of the source document, which is in some dialect of xml).
>
> However, I don't know what the position would be about a completely new module.
>
> Cheers, John.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
news
Posted by Tony Dahbura <to...@dahbura.com>.
John:
I never heard anymore on the pooling stuff you and I were working on. Has there
been any headway with Craig on this. Sorry I have been traveling some lately and
may not be caught up on my emails.
Tony
John Holman wrote:
> 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 module that allows utlization of ldap features that may or may
> >not be
> >possible through the JNDI layer.
>
> As far as I can see, writing a "native LDAP realm module" - if by that you
> mean using the API provided by the Netscape directory SDK rather than Sun's
> JNDI API - would make little difference to the functionality possible.
> There may be performance benefits, though I have read conflicting reports
> on that.
>
> >The items I am looking at designing into this module are:
> >1-Connection pooling to support high performance access
> >2-HA capabilities to support failover if a server goes away
> >3-Authentication via the server rather than comparison of the passwords in
> >digested forms (this option will also be supported)
> >4-support for other realm group models (still checking into this).
> >5-User location without DN identification (no need to be able to build the
> >DN to
> >find the user)
> >6-SSL support for communications
>
> Some history ...
>
> The current JNDIRealm implementation in Tomcat 4 is based on code I
> proposed back in April last year. I believe the existing implementation is
> sufficiently flexible to cover most ways of representing group information
> in the directory (item 4), and adding SSL support (item 6) should be
> trivial. However item 3 (authentication by binding to the directory as the
> user rather than by retrieving credentials and comparing them explicitly in
> the realm) and feature 5 (essentially, finding the user's DN by searching
> the directory on an arbitrary attribute) are not included. I think items 3
> and 5 are essential if the module is to be of much practical use.
>
> In fact my original proposal did include much of the missing functionality
> (though not the performance and availability enhancements you mention).
> Craig made several significant improvements to the code before committing
> it, but also removed support for items 3 and 5. I subsequently proposed a
> patch restoring item 3, and planned to propose a second patch restoring
> item 5 if the first patch was accepted. Craig's response was that we should
> first get agreement on top-level goals, and proposed a functional
> specification for the JNDI Realm which is included in the Tomcat release
> documentation. This spec includes two "login modes" which cover item 3, but
> says little about the other items.
>
> As far as I know there has been no discussion of the spec since then, and
> it still has proposed status. So perhaps the next step before enhancing the
> existing module would be for the group to reach agreement about the
> required features and produce a revised spec. I'm afraid I never got round
> to proposing changes to the spec myself but now the subject has come up
> again I will try to have a go at it. (I'll probably need to look at the
> format of the source document, which is in some dialect of xml).
>
> However, I don't know what the position would be about a completely new module.
>
> Cheers, John.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for a new realm module for tomcat
Posted by John Holman <j....@qmul.ac.uk>.
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 module that allows utlization of ldap features that may or may
>not be
>possible through the JNDI layer.
As far as I can see, writing a "native LDAP realm module" - if by that you
mean using the API provided by the Netscape directory SDK rather than Sun's
JNDI API - would make little difference to the functionality possible.
There may be performance benefits, though I have read conflicting reports
on that.
>The items I am looking at designing into this module are:
>1-Connection pooling to support high performance access
>2-HA capabilities to support failover if a server goes away
>3-Authentication via the server rather than comparison of the passwords in
>digested forms (this option will also be supported)
>4-support for other realm group models (still checking into this).
>5-User location without DN identification (no need to be able to build the
>DN to
>find the user)
>6-SSL support for communications
Some history ...
The current JNDIRealm implementation in Tomcat 4 is based on code I
proposed back in April last year. I believe the existing implementation is
sufficiently flexible to cover most ways of representing group information
in the directory (item 4), and adding SSL support (item 6) should be
trivial. However item 3 (authentication by binding to the directory as the
user rather than by retrieving credentials and comparing them explicitly in
the realm) and feature 5 (essentially, finding the user's DN by searching
the directory on an arbitrary attribute) are not included. I think items 3
and 5 are essential if the module is to be of much practical use.
In fact my original proposal did include much of the missing functionality
(though not the performance and availability enhancements you mention).
Craig made several significant improvements to the code before committing
it, but also removed support for items 3 and 5. I subsequently proposed a
patch restoring item 3, and planned to propose a second patch restoring
item 5 if the first patch was accepted. Craig's response was that we should
first get agreement on top-level goals, and proposed a functional
specification for the JNDI Realm which is included in the Tomcat release
documentation. This spec includes two "login modes" which cover item 3, but
says little about the other items.
As far as I know there has been no discussion of the spec since then, and
it still has proposed status. So perhaps the next step before enhancing the
existing module would be for the group to reach agreement about the
required features and produce a revised spec. I'm afraid I never got round
to proposing changes to the spec myself but now the subject has come up
again I will try to have a go at it. (I'll probably need to look at the
format of the source document, which is in some dialect of xml).
However, I don't know what the position would be about a completely new module.
Cheers, John.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Proposal for a new realm module for tomcat
Posted by Tony Dahbura <to...@dahbura.com>.
Team:
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 module that allows utlization of ldap features that may or may not be
possible through the JNDI layer.
The items I am looking at designing into this module are:
1-Connection pooling to support high performance access
2-HA capabilities to support failover if a server goes away
3-Authentication via the server rather than comparison of the passwords in
digested forms (this option will also be supported)
4-support for other realm group models (still checking into this).
5-User location without DN identification (no need to be able to build the DN to
find the user)
6-SSL support for communications
The LDAPRealm module will contain and deliver all the functions that the current
JNDI module provides, but will also include additional functions for high
performance and HA support as well as native LDAP functionality.
I have started preliminary work on this, but wanted to see what the group
thought about this. I have been watching a couple queries from the list on this
as well as chatting with other folks on the net about their use of LDAP.
Thanks,
Tony
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with JNDIRealm ...
Posted by Shelly <sw...@yahoo.com>.
Tony,
Thank you very much for your response.
You mentioned that you are in the process of starting to code this JNDI
implementation, when you done, please let me know, as I'm interested in
trying to get JNDIRealm to work.
Does SHA digest will been supported in this implementation?
Thanks,
Shelly
Tony Dahbura wrote:
>
> Shelly:
> I did not want to copy the whole list on your first question. What you are
> trying to accomplish is a search to authenticate a user when the uid is not part
> of the dn. I do not believe the JNDI implementation supports this now.
>
> I am actually proposing to the group that we implement a full ldap realm module
> that does not run on top of JNDI but instead utilizes full ldap functionality to
> do things like you are trying to do.
>
> I am in the process of starting to code this. I will have a proposal out for
> the group in the next week.
>
> Tony
>
> Shelly wrote:
>
> > Hello,
> >
> > I'm running Tomcat 4 on Unix and trying to use JNDIRealm for
> > authentication.
> > I use Netscape LDAP server, and the hierarchy of entries in the directory
> > is
> >
> > o=My Company
> > |
> > +---------------+---------------+
> > | | |
> > ou=People ou=Groups ...
> > |
> > +-------+-------+
> > | |
> > ou=Employee ...
> > |
> > +-----+-----+
> > | | |
> > enum=001 ... enum=111
> >
> > However, the login attribute is uid.
> >
> > When I do a search for a valid uid, it returns null.
> >
> > If I use DirContext.listBindings("") to get name-to-objects, no object
> > returns; (Please see code below).
> > If I use DirContext.listBindings("o=My Company") to get name-to-objects,
> > it returns (Name: ClassName: Object):
> > ou=Resources: com.sun.jndi.ldap.LdapCtx:
> > com.sun.jndi.ldap.LdapCtx@586fd3
> > ou=People: com.sun.jndi.ldap.LdapCtx: com.sun.jndi.ldap.LdapCtx@586jhk
> > ...
> >
> > Hash table en = new Hash table();
> > env.put(Context.INITIAL_CONTEXT_FACTORY, contextFactory);
> > if (connection Name != null)
> > env.put(Context.SECURITY_PRINCIPAL, connectionName);
> > if (connection Password != null)
> > env.put(Context.SECURITY_CREDENTIALS, connectionPassword);
> > if (connection URL != null)
> > env.put(Context.PROVIDER_URL, connectionURL);
> > context = new InitialDirContext(env);
> >
> > try {
> > // Get listing of context
> > Naming Enumeration bindings = context.listBindings("");
> > // Go through each item in list
> > while (bindings.hasMore()) {
> > Binding bd = (Binding)bindings.next();
> > log(bd.getName() + ": " + bd.getClassName() + ": " +
> > bd.getObject());
> > }
> > } catch (Naming Exception e) {
> > log("List Bindings failed: " + e);
> > }
> >
> > If I bind dn="", I got "HTTP Status 500 - Internal Server Error" message
> > when I access the secured page.
> >
> > I'm wondering if anyone knows the answers to any of the following
> > questions:
> >
> > 1. How to get a dn from uid when uid is not part of the dn?
> > 2. Does SHA digest been supported? When DAP server use SHA digest for
> > userPassword, how do I encrypt SHA digest?
> > 3. How to use an anonymous password for binding instead of using
> > connectionName/connectionPassword?
> >
> > Thanks
> >
> > Shelly
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with JNDIRealm ...
Posted by Tony Dahbura <to...@dahbura.com>.
Shelly:
I did not want to copy the whole list on your first question. What you are
trying to accomplish is a search to authenticate a user when the uid is not part
of the dn. I do not believe the JNDI implementation supports this now.
I am actually proposing to the group that we implement a full ldap realm module
that does not run on top of JNDI but instead utilizes full ldap functionality to
do things like you are trying to do.
I am in the process of starting to code this. I will have a proposal out for
the group in the next week.
Tony
Shelly wrote:
> Hello,
>
> I'm running Tomcat 4 on Unix and trying to use JNDIRealm for
> authentication.
> I use Netscape DAP server, and the hierarchy of entries in the directory
> is
>
> o=My Company
> |
> +---------------+---------------+
> | | |
> ou=People ou=Groups ...
> |
> +-------+-------+
> | |
> ou=Employee ...
> |
> +-----+-----+
> | | |
> enum=001 ... enum=111
>
> However, the logic attribute is uid.
>
> When I do a search for a valid uid, it returns null.
>
> If I use DirContext.listBindings("") to get name-to-objects, no object
> returns; (Please see code below).
> If I use DirContext.listBindings("o=My Company") to get name-to-objects,
> it returns (Name: ClassName: Object):
> ou=Resources: com.sun.jndi.ldap.LdapCtx:
> com.sun.jndi.ldap.LdapCtx@586fd3
> ou=People: com.sun.jndi.ldap.LdapCtx: com.sun.jndi.ldap.LdapCtx@586jhk
> ...
>
> Hash table en = new Hash table();
> env.put(Context.INITIAL_CONTEXT_FACTORY, context Factory);
> if (connection Name != null)
> env.put(Context.SECURITY_PRINCIPAL, connection Name);
> if (connection Password != null)
> env.put(Context.SECURITY_CREDENTIALS, connection Password);
> if (connection URL != null)
> env.put(Context.PROVIDER_URL, connection URL);
> context = new InitialDirContext(env);
>
> try {
> // Get listing of context
> Naming Enumeration bindings = context.listBindings("");
> // Go through each item in list
> while (bindings.hasMore()) {
> Binding bd = (Binding)bindings.next();
> log(bd.getName() + ": " + bd.getClassName() + ": " +
> bd.getObject());
> }
> } catch (Naming Exception e) {
> log("List Bindings failed: " + e);
> }
>
> If I bind dn."", I got "HTTP Status 500 - Internal Server Error" message
> when I access the secured page.
>
> I'm wondering if anyone knows the answers to any of the following
> questions:
>
> 1. How to get a dn from uid when uid is not part of the dn?
> 2. Does SHA digest been supported? When DAP server use SHA digest for
> userPassword, how do I encrypt SHA digest?
> 3. How to use an anonymous password for binding instead of using
> connectionName/connectionPassword?
>
> Thanks
>
> Shelly
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with JNDIRealm ...
Posted by Shelly <sw...@yahoo.com>.
Tony,
I tried to use both connectionName="" and connectionPassword="" to
connect to LDAP, however the userPassword returns null (in this case, I
used enum as login attribute), authentication failed.
Regards,
Shelly
Tony Dahbura wrote:
>
> Shelly:
> Let me help with number 3
>
> The typical standard for anonymous binding is to specify a name and password of
> "" "" for both. I am not sure if JNDI will pass this ok-give it a try.
>
> 3. How to use an anonymous password for binding instead of using
> connectionName/connectionPassword?
>
> Shelly wrote:
>
> > Hello,
> >
> > I'm running Tomcat 4 on Unix and trying to use JNDIRealm for
> > authentication.
> > I use Netscape DAP server, and the hierarchy of entries in the directory
> > is
> >
> > o=My Company
> > |
> > +---------------+---------------+
> > | | |
> > ou=People ou=Groups ...
> > |
> > +-------+-------+
> > | |
> > ou=Employee ...
> > |
> > +-----+-----+
> > | | |
> > enum=001 ... enum=111
> >
> > However, the login attribute is uid.
> >
> > When I do a search for a valid uid, it returns null.
> >
> > If I use DirContext.listBindings("") to get name-to-objects, no object
> > returns; (Please see code below).
> > If I use DirContext.listBindings("o=My Company") to get name-to-objects,
> > it returns (Name: ClassName: Object):
> > ou=Resources: com.sun.jndi.ldap.LdapCtx:
> > com.sun.jndi.ldap.LdapCtx@586fd3
> > ou=People: com.sun.jndi.ldap.LdapCtx: com.sun.jndi.ldap.LdapCtx@586jhk
> > ...
> >
> > Hash table en = new Hash table();
> > env.put(Context.INITIAL_CONTEXT_FACTORY, contextFactory);
> > if (connection Name != null)
> > env.put(Context.SECURITY_PRINCIPAL, connectionName);
> > if (connection Password != null)
> > env.put(Context.SECURITY_CREDENTIALS, connectionPassword);
> > if (connection URL != null)
> > env.put(Context.PROVIDER_URL, connectionURL);
> > context = new InitialDirContext(env);
> >
> > try {
> > // Get listing of context
> > Naming Enumeration bindings = context.listBindings("");
> > // Go through each item in list
> > while (bindings.hasMore()) {
> > Binding bd = (Binding)bindings.next();
> > log(bd.getName() + ": " + bd.getClassName() + ": " +
> > bd.getObject());
> > }
> > } catch (Naming Exception e) {
> > log("List Bindings failed: " + e);
> > }
> >
> > If I bind dn="", I got "HTTP Status 500 - Internal Server Error" message
> > when I access the secured page.
> >
> > I'm wondering if anyone knows the answers to any of the following
> > questions:
> >
> > 1. How to get a dn from uid when uid is not part of the dn?
> > 2. Does SHA digest been supported? When LDAP server use SHA digest for
> > userPassword, how do I encrypt SHA digest?
> > 3. How to use an anonymous password for binding instead of using
> > connectionName/connectionPassword?
> >
> > Thanks
> >
> > Shelly
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with JNDIRealm ...
Posted by Tony Dahbura <to...@dahbura.com>.
Shelly:
Let me help with number 3
The typical standard for anonymous binding is to specify a name and password of
"" "" for both. I am not sure if JNDI will pass this ok-give it a try.
3. How to use an anonymous password for binding instead of using
connectionName/connectionPassword?
Shelly wrote:
> Hello,
>
> I'm running Tomcat 4 on Unix and trying to use JNDIRealm for
> authentication.
> I use Netscape DAP server, and the hierarchy of entries in the directory
> is
>
> o=My Company
> |
> +---------------+---------------+
> | | |
> ou=People ou=Groups ...
> |
> +-------+-------+
> | |
> ou=Employee ...
> |
> +-----+-----+
> | | |
> enum=001 ... enum=111
>
> However, the logic attribute is uid.
>
> When I do a search for a valid uid, it returns null.
>
> If I use DirContext.listBindings("") to get name-to-objects, no object
> returns; (Please see code below).
> If I use DirContext.listBindings("o=My Company") to get name-to-objects,
> it returns (Name: ClassName: Object):
> ou=Resources: com.sun.jndi.ldap.LdapCtx:
> com.sun.jndi.ldap.LdapCtx@586fd3
> ou=People: com.sun.jndi.ldap.LdapCtx: com.sun.jndi.ldap.LdapCtx@586jhk
> ...
>
> Hash table en = new Hash table();
> env.put(Context.INITIAL_CONTEXT_FACTORY, context Factory);
> if (connection Name != null)
> env.put(Context.SECURITY_PRINCIPAL, connection Name);
> if (connection Password != null)
> env.put(Context.SECURITY_CREDENTIALS, connection Password);
> if (connection URL != null)
> env.put(Context.PROVIDER_URL, connection URL);
> context = new InitialDirContext(env);
>
> try {
> // Get listing of context
> Naming Enumeration bindings = context.listBindings("");
> // Go through each item in list
> while (bindings.hasMore()) {
> Binding bd = (Binding)bindings.next();
> log(bd.getName() + ": " + bd.getClassName() + ": " +
> bd.getObject());
> }
> } catch (Naming Exception e) {
> log("List Bindings failed: " + e);
> }
>
> If I bind dn."", I got "HTTP Status 500 - Internal Server Error" message
> when I access the secured page.
>
> I'm wondering if anyone knows the answers to any of the following
> questions:
>
> 1. How to get a dn from uid when uid is not part of the dn?
> 2. Does SHA digest been supported? When DAP server use SHA digest for
> userPassword, how do I encrypt SHA digest?
> 3. How to use an anonymous password for binding instead of using
> connectionName/connectionPassword?
>
> Thanks
>
> Shelly
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>