RE: LDAP Authentication

[Mitchell Christensen]

This is only true for MemoryRealms.  RDBMS & JNDI Realms *do not* require a
server restart.

-Mitch

-Original Message-
From: Gonzalo A. Diethelm [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 11:42 AM
To: Turbine Developers List
Subject: RE: LDAP Authentication


> > Realm base authentication is a Servlet 2.3 specification.  As such, any
> > container which is 2.3 compliant will support Realm based 
> > authentication.
> 
> In that case, +1 for Realm based authentication.

I believe one of the reasons Turbine didn't use this is because it
is not possible to create users without restarting the servlet container.
This would not be good for a traditional webapp setup, where you might
want users to register themselves.

> -Eric


-- 
Gonzalo A. Diethelm
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: LDAP Authentication

[Gonzalo A. Diethelm]

> > Realm base authentication is a Servlet 2.3 specification.  As such, any
> > container which is 2.3 compliant will support Realm based 
> > authentication.
> 
> In that case, +1 for Realm based authentication.

I believe one of the reasons Turbine didn't use this is because it
is not possible to create users without restarting the servlet container.
This would not be good for a traditional webapp setup, where you might
want users to register themselves.

> -Eric


-- 
Gonzalo A. Diethelm
[EMAIL PROTECTED]


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

Re: LDAP Authentication

[Eric Dobbs]

On Monday, February 4, 2002, at 10:03  AM, Mitchell Christensen wrote:

> Realm base authentication is a Servlet 2.3 specification.  As such, any
> container which is 2.3 compliant will support Realm based 
> authentication.

In that case, +1 for Realm based authentication.

-Eric

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

RE: LDAP Authentication

[Mitchell Christensen]

Realm base authentication is a Servlet 2.3 specification.  As such, any
container which is 2.3 compliant will support Realm based authentication.

If we focus on authentication based on the Servlet specification, rather
than Tomcat's specific implementation, I think we will still be ok.  Then
whichever method(s) a container chooses to support
(RDBMS/Memory/JNDI/XML/etc) will be available to Turbine.

-Mitch

-Original Message-
From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 8:59 AM
To: Turbine Developers List
Subject: Re: LDAP Authentication



On Monday, February 4, 2002, at 09:26  AM, Mitchell Christensen wrote:

> While I was originally enthusiastic about the inclusion of LDAP
> authentication as a natural extension of Turbine, I'm now wondering why
> Turbine builds it's own authentication scheme rather than using the
> underlying Servlet 2.3 Realm (JNDIRealm) model build into Tomcat?

I think this was probably motivated by a desire to allow
Turbine apps to be portable across servlet containers.
Relying on a tomcat feature might cause the apps to break
when deployed on non-tomcat containers.

-Eric

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: LDAP Authentication

[Eric Dobbs]

On Monday, February 4, 2002, at 09:26  AM, Mitchell Christensen wrote:

> While I was originally enthusiastic about the inclusion of LDAP
> authentication as a natural extension of Turbine, I'm now wondering why
> Turbine builds it's own authentication scheme rather than using the
> underlying Servlet 2.3 Realm (JNDIRealm) model build into Tomcat?

I think this was probably motivated by a desire to allow
Turbine apps to be portable across servlet containers.
Relying on a tomcat feature might cause the apps to break
when deployed on non-tomcat containers.

-Eric

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

RE: LDAP Authentication

[Mitchell Christensen]

Colin,

I would be interested in working on this effort with you.  However, as my
previous post points out, I think we should seriously consider using the
Servlet Realm based authentication model, and building on top of that rather
than duplicating (and bypassing) that functionality.

As for your thought about how to implement JNDI, I totally agree that the
peer model should be extended to include non-relational data stores
(XMLDB/JNDI/etc.).  But I see that as a parallel effort.  If we extended the
peer model to support JNDI, then it would be far simpler (possibly no work
at all) to have flux work with a JNDI based data store.  If we provide a
mechanism for Turbine to access the (Servlet 2.3 compliant) Realm based
authentication model provided by the underlying servlet engine (Tomcat),
possibly even as an alternative to the current model at first, we get
automatic Memory/RDBMS/JNDI based authentication, with added advantage of
authentication across web applications.
 
This seems like the "best" solution to me.

-Mitch

-Original Message-
From: Colin Chalmers [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 5:36 AM
To: Turbine Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: LDAP Authentication


I too have a genuine interest in getting Turbine to work with Ldap. I have
mentioned this once or twice on the list and briefly discussed this with
Jason. However due to higher priorities I haven't actually got round to
doing anything about it *ashamed*

The code that was once donated wasn't really up to scratch and has since
been removed. Perhaps it's once again time to throw around a couple of ideas
to see if we can work something out and get *something acceptable* up &
running. Mitch would you be willing to work on this with me?

Some input from other members would be beneficial to reach the best solution
& increase acceptance when it comes.

For example is it an idea to try and have a (JNDI) adaptor based roughly on
the same style as the DB adaptors? Making use of a common connectionPool
mechansim? Peer integration? Or should we keep the JNDI stuff seperate from
the DB stuuf altogether???

I'm trying to think along the lines that it should be pluggable and
transparent to the app. programmer, so instead of querying a DB it's an Ldap
server you're querying.

Input sought & appreciated. Mitch perhaps we could take our discussion
off-line to see what we can come up with.

/Colin



- Original Message -
From: "Mitchell Christensen" <[EMAIL PROTECTED]>
To: "'Turbine Developers List'" <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2002 12:52 AM
Subject: RE: LDAP Authentication


> Hey Eric,
>
> You are correct.  The most recent list of JNDI service providers
> (http://java.sun.com/products/jndi/serviceproviders.html#12)
> includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System,
Novell
> and the Windows Registry.  I think that a JNDISecurityService is the way
to
> go, but you're right, I should probably focus on the LDAPSecurityService
> given my schedule and make it LDAP specific.
>
> I did send a message directly to Jason, and one other (I don't remember
> which) 2+ days ago and recieved no response.  Hopefully they'll hit this
> discussion and want to get involved.
>
> I think that in the meantime I'll subclass LDAPUserManager and
> LDAPSecurityService and get things working like that.  Once that works,
I'll
> share those files and we can discuss how to best implement the changes
> within Turbine.
>
> Sound reasonable?
>
> -Mitch
>
> PS I'm all for a better "long-term" solution, and would be interested in
> participating, time permitting.
>
> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 3:22 PM
> To: Turbine Developers List
> Subject: Re: LDAP Authentication
>
>
>
> On Friday, February 1, 2002, at 02:49  PM, Mitchell Christensen wrote:
>
> > After looking at the code, I'm wondering if this shouldn't be
> > implemented using the om/peer model, but that is meant solely for RDBMS
> > right now (correct? Its a different discussion altogether, but why can't
> > objects be mapped to LDAP as well?).  For now I was thinking about
> > simply
> > putting the JNDI calls directly in the LDAPSecurityService.
>
> Couple things.
> om/peers are definitely DB biased right now.  There has been some
> talk of abstracting that to support an XML backend, and I think
> your suggestion of LDAP is not unreasonable in the context of that
> discussion.  I suspect that is a bigger project than your specific
> need calls for.
>
> I don't have much experience with JNDI nor LDAP.  My intuition is
> that a JNDISecurity

RE: LDAP Authentication

[Mitchell Christensen]

While I was originally enthusiastic about the inclusion of LDAP
authentication as a natural extension of Turbine, I'm now wondering why
Turbine builds it's own authentication scheme rather than using the
underlying Servlet 2.3 Realm (JNDIRealm) model build into Tomcat?

It seems more natural to simply extend the Realm implementation to enable
the admittedly nice permission/role/group model provided by Turbine.  Then
people could use whatever authentication model they like (LDAP/RDBMS/Memory)
and still access the Turbine permissions.

This solves a rather significant problem needing to do single sign-on across
multiple webapps.  I'll assert, in the interest of fostering discussion,
that you can't do that with the Turbine model.  The Turbine model
authenticates within a servlet context (webapp), but not across them, as the
Tomcat implementation of the Servlet 2.3 Realm model supports.

Also, if you look at the Turbine LDAPUserManager.java and the Tomcat
JNDIRealm.java you'll notice immense logical similarity.  Why duplicate this
code? 

Chris, as for your SSL questions, since the interaction between Turbine and
the LDAP server takes place behind our firewall, I wasn't planning on using
SSL.  But I'm open to arguments to in favor of it :).

-Mitch

-Original Message-
From: Chris Holman [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 5:33 AM
To: Turbine Developers List
Subject: RE: LDAP Authentication


I would be interested in getting involved with this.

We are planning a set of turbine web app's that I would like to authenticate
via LDAP over SSL.
Mitchell: Do you intended to implement the LDAP SSL features?
If not, perhaps we can take an aside to design this into the class
hierarchy?

Chris

> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: 02 February 2002 00:28
> To: Turbine Developers List
> Subject: Re: LDAP Authentication
>
>
> On Friday, February 1, 2002, at 04:52  PM, Mitchell Christensen wrote:
>
> > You are correct.  The most recent list of JNDI service providers
> > (http://java.sun.com/products/jndi/serviceproviders.html#12)
> > includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System,
> > Novell
> > and the Windows Registry.  I think that a JNDISecurityService is the
> > way to
> > go, but you're right, I should probably focus on the LDAPSecurityService
> > given my schedule and make it LDAP specific.
>
> I love it when my intuition matches reality!  Thanks.
>
> LDAP by itself would probably make quite a few people happy.
> And tt is your itch to scratch after all.
>
>
> > I did send a message directly to Jason, and one other (I don't remember
> > which) 2+ days ago and recieved no response.  Hopefully they'll hit this
> > discussion and want to get involved.
>
> Jason is only just getting back from a trip to NYC.  He'll have
> some email to catch up on, I'm sure.
>
>
> > I think that in the meantime I'll subclass LDAPUserManager and
> > LDAPSecurityService and get things working like that.  Once that works,
> > I'll
> > share those files and we can discuss how to best implement the changes
> > within Turbine.
> >
> > Sound reasonable?
>
> yep.
>
>
> > PS I'm all for a better "long-term" solution, and would be interested in
> > participating, time permitting.
>
> +1
>
>
> -Eric
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: LDAP Authentication

[Colin Chalmers]

I too have a genuine interest in getting Turbine to work with Ldap. I have
mentioned this once or twice on the list and briefly discussed this with
Jason. However due to higher priorities I haven't actually got round to
doing anything about it *ashamed*

The code that was once donated wasn't really up to scratch and has since
been removed. Perhaps it's once again time to throw around a couple of ideas
to see if we can work something out and get *something acceptable* up &
running. Mitch would you be willing to work on this with me?

Some input from other members would be beneficial to reach the best solution
& increase acceptance when it comes.

For example is it an idea to try and have a (JNDI) adaptor based roughly on
the same style as the DB adaptors? Making use of a common connectionPool
mechansim? Peer integration? Or should we keep the JNDI stuff seperate from
the DB stuuf altogether???

I'm trying to think along the lines that it should be pluggable and
transparent to the app. programmer, so instead of querying a DB it's an Ldap
server you're querying.

Input sought & appreciated. Mitch perhaps we could take our discussion
off-line to see what we can come up with.

/Colin



- Original Message -
From: "Mitchell Christensen" <[EMAIL PROTECTED]>
To: "'Turbine Developers List'" <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2002 12:52 AM
Subject: RE: LDAP Authentication


> Hey Eric,
>
> You are correct.  The most recent list of JNDI service providers
> (http://java.sun.com/products/jndi/serviceproviders.html#12)
> includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System,
Novell
> and the Windows Registry.  I think that a JNDISecurityService is the way
to
> go, but you're right, I should probably focus on the LDAPSecurityService
> given my schedule and make it LDAP specific.
>
> I did send a message directly to Jason, and one other (I don't remember
> which) 2+ days ago and recieved no response.  Hopefully they'll hit this
> discussion and want to get involved.
>
> I think that in the meantime I'll subclass LDAPUserManager and
> LDAPSecurityService and get things working like that.  Once that works,
I'll
> share those files and we can discuss how to best implement the changes
> within Turbine.
>
> Sound reasonable?
>
> -Mitch
>
> PS I'm all for a better "long-term" solution, and would be interested in
> participating, time permitting.
>
> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 3:22 PM
> To: Turbine Developers List
> Subject: Re: LDAP Authentication
>
>
>
> On Friday, February 1, 2002, at 02:49  PM, Mitchell Christensen wrote:
>
> > After looking at the code, I'm wondering if this shouldn't be
> > implemented using the om/peer model, but that is meant solely for RDBMS
> > right now (correct? Its a different discussion altogether, but why can't
> > objects be mapped to LDAP as well?).  For now I was thinking about
> > simply
> > putting the JNDI calls directly in the LDAPSecurityService.
>
> Couple things.
> om/peers are definitely DB biased right now.  There has been some
> talk of abstracting that to support an XML backend, and I think
> your suggestion of LDAP is not unreasonable in the context of that
> discussion.  I suspect that is a bigger project than your specific
> need calls for.
>
> I don't have much experience with JNDI nor LDAP.  My intuition is
> that a JNDISecurityService would be more generally useful than
> something specific to LDAP.  Your coment about JNDI calls leads me
> to believe you have experience to verify whether my intuition is
> correct or not.  I understand there exist JNDI adaptors for NIS+,
> and LDAP, and others...  might just be another case of "a small
> amount of knowledge can be dangerous."  8^)
>
> In any case, JNDI calls in the LDAPSecurityService sounds like the
> shortest route at the moment.
>
>
> > Also, the current implementation won't bind (authenticate) against
> > Netscape
> > Directory Server.  I understand the problem, but won't go into it here
> > because it is somewhat long-winded.  There will need to be a change or
> > two
> > to the LDAPUserManager as well.
>
> No surprise that LDAPUserManager needs work.  It's part of the whole
> bundle that was abandoned in Turbine's CVS repository.  Your attention
> to the matter will be very welcome.
>
>
> > Would it be fare to ask for a brain dump from anyone who has thoughts
> > on how
> > this should be done in exchange for building the LDAP interface and
> > submitt

RE: LDAP Authentication

[Chris Holman]

I would be interested in getting involved with this.

We are planning a set of turbine web app's that I would like to authenticate
via LDAP over SSL.
Mitchell: Do you intended to implement the LDAP SSL features?
If not, perhaps we can take an aside to design this into the class
hierarchy?

Chris

> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: 02 February 2002 00:28
> To: Turbine Developers List
> Subject: Re: LDAP Authentication
>
>
> On Friday, February 1, 2002, at 04:52  PM, Mitchell Christensen wrote:
>
> > You are correct.  The most recent list of JNDI service providers
> > (http://java.sun.com/products/jndi/serviceproviders.html#12)
> > includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System,
> > Novell
> > and the Windows Registry.  I think that a JNDISecurityService is the
> > way to
> > go, but you're right, I should probably focus on the LDAPSecurityService
> > given my schedule and make it LDAP specific.
>
> I love it when my intuition matches reality!  Thanks.
>
> LDAP by itself would probably make quite a few people happy.
> And tt is your itch to scratch after all.
>
>
> > I did send a message directly to Jason, and one other (I don't remember
> > which) 2+ days ago and recieved no response.  Hopefully they'll hit this
> > discussion and want to get involved.
>
> Jason is only just getting back from a trip to NYC.  He'll have
> some email to catch up on, I'm sure.
>
>
> > I think that in the meantime I'll subclass LDAPUserManager and
> > LDAPSecurityService and get things working like that.  Once that works,
> > I'll
> > share those files and we can discuss how to best implement the changes
> > within Turbine.
> >
> > Sound reasonable?
>
> yep.
>
>
> > PS I'm all for a better "long-term" solution, and would be interested in
> > participating, time permitting.
>
> +1
>
>
> -Eric
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: LDAP Authentication

[Eric Dobbs]

On Friday, February 1, 2002, at 04:52  PM, Mitchell Christensen wrote:

> You are correct.  The most recent list of JNDI service providers
> (http://java.sun.com/products/jndi/serviceproviders.html#12)
> includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System, 
> Novell
> and the Windows Registry.  I think that a JNDISecurityService is the 
> way to
> go, but you're right, I should probably focus on the LDAPSecurityService
> given my schedule and make it LDAP specific.

I love it when my intuition matches reality!  Thanks.

LDAP by itself would probably make quite a few people happy.
And tt is your itch to scratch after all.


> I did send a message directly to Jason, and one other (I don't remember
> which) 2+ days ago and recieved no response.  Hopefully they'll hit this
> discussion and want to get involved.

Jason is only just getting back from a trip to NYC.  He'll have
some email to catch up on, I'm sure.


> I think that in the meantime I'll subclass LDAPUserManager and
> LDAPSecurityService and get things working like that.  Once that works, 
> I'll
> share those files and we can discuss how to best implement the changes
> within Turbine.
>
> Sound reasonable?

yep.


> PS I'm all for a better "long-term" solution, and would be interested in
> participating, time permitting.

+1


-Eric

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

RE: LDAP Authentication

[Mitchell Christensen]

Hey Eric,

You are correct.  The most recent list of JNDI service providers
(http://java.sun.com/products/jndi/serviceproviders.html#12) 
includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System, Novell
and the Windows Registry.  I think that a JNDISecurityService is the way to
go, but you're right, I should probably focus on the LDAPSecurityService
given my schedule and make it LDAP specific.

I did send a message directly to Jason, and one other (I don't remember
which) 2+ days ago and recieved no response.  Hopefully they'll hit this
discussion and want to get involved.

I think that in the meantime I'll subclass LDAPUserManager and
LDAPSecurityService and get things working like that.  Once that works, I'll
share those files and we can discuss how to best implement the changes
within Turbine.

Sound reasonable?

-Mitch

PS I'm all for a better "long-term" solution, and would be interested in
participating, time permitting.

-Original Message-
From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 3:22 PM
To: Turbine Developers List
Subject: Re: LDAP Authentication



On Friday, February 1, 2002, at 02:49  PM, Mitchell Christensen wrote:

> After looking at the code, I'm wondering if this shouldn't be
> implemented using the om/peer model, but that is meant solely for RDBMS
> right now (correct? Its a different discussion altogether, but why can't
> objects be mapped to LDAP as well?).  For now I was thinking about 
> simply
> putting the JNDI calls directly in the LDAPSecurityService.

Couple things.
om/peers are definitely DB biased right now.  There has been some
talk of abstracting that to support an XML backend, and I think
your suggestion of LDAP is not unreasonable in the context of that
discussion.  I suspect that is a bigger project than your specific
need calls for.

I don't have much experience with JNDI nor LDAP.  My intuition is
that a JNDISecurityService would be more generally useful than
something specific to LDAP.  Your coment about JNDI calls leads me
to believe you have experience to verify whether my intuition is
correct or not.  I understand there exist JNDI adaptors for NIS+,
and LDAP, and others...  might just be another case of "a small
amount of knowledge can be dangerous."  8^)

In any case, JNDI calls in the LDAPSecurityService sounds like the
shortest route at the moment.


> Also, the current implementation won't bind (authenticate) against 
> Netscape
> Directory Server.  I understand the problem, but won't go into it here
> because it is somewhat long-winded.  There will need to be a change or 
> two
> to the LDAPUserManager as well.

No surprise that LDAPUserManager needs work.  It's part of the whole
bundle that was abandoned in Turbine's CVS repository.  Your attention
to the matter will be very welcome.


> Would it be fare to ask for a brain dump from anyone who has thoughts 
> on how
> this should be done in exchange for building the LDAP interface and
> submitting?  I noticed that Jason van Zyl, Leonard Flournoy, Tracy 
> Adewunmi
> and Rafal Krzewski were listed as original authors.  Are they still 
> around?
> Is there some original design notes, etc. that might be of use?

JvZ is definitely around, but very busy on lots of other projects.  I
think he's presently traveling but I'm sure he'll add to the
conversation when he gets back.  The rest I can't say.

Colin Chalmers and some of his colleagues have discussed this before on
the turbine-user list.  I remember some discussion about an LDAP schema
and DNs and such (exposing more ignorance, I know 8^).

Here's a link to the archive that should get you too the relevant thread.
http://www.mail-archive.com/turbine-
user%40jakarta.apache.org/msg02150.html
Paul Esposito's name is one this one.  I am fairly certain that nothing
ever came of this thread (or the LDAP stuff would be working now).  It
might be worth firing an email off to those two to see if they have any
time they can offer to help.  They have at least have more experience to
bring in this area.

I'm happy to lend a hand (maybe it'll give me an excuse to finally
learn LDAP and JNDI 8^).


> I'm going to cross-post this to turbine-dev since that is probably where
> this thread should be anyways.

good move.  this is definitely the right place for the conversation.


-Eric

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: LDAP Authentication

[Eric Dobbs]

On Friday, February 1, 2002, at 02:49  PM, Mitchell Christensen wrote:

> After looking at the code, I'm wondering if this shouldn't be
> implemented using the om/peer model, but that is meant solely for RDBMS
> right now (correct? Its a different discussion altogether, but why can't
> objects be mapped to LDAP as well?).  For now I was thinking about 
> simply
> putting the JNDI calls directly in the LDAPSecurityService.

Couple things.
om/peers are definitely DB biased right now.  There has been some
talk of abstracting that to support an XML backend, and I think
your suggestion of LDAP is not unreasonable in the context of that
discussion.  I suspect that is a bigger project than your specific
need calls for.

I don't have much experience with JNDI nor LDAP.  My intuition is
that a JNDISecurityService would be more generally useful than
something specific to LDAP.  Your coment about JNDI calls leads me
to believe you have experience to verify whether my intuition is
correct or not.  I understand there exist JNDI adaptors for NIS+,
and LDAP, and others...  might just be another case of "a small
amount of knowledge can be dangerous."  8^)

In any case, JNDI calls in the LDAPSecurityService sounds like the
shortest route at the moment.


> Also, the current implementation won't bind (authenticate) against 
> Netscape
> Directory Server.  I understand the problem, but won't go into it here
> because it is somewhat long-winded.  There will need to be a change or 
> two
> to the LDAPUserManager as well.

No surprise that LDAPUserManager needs work.  It's part of the whole
bundle that was abandoned in Turbine's CVS repository.  Your attention
to the matter will be very welcome.


> Would it be fare to ask for a brain dump from anyone who has thoughts 
> on how
> this should be done in exchange for building the LDAP interface and
> submitting?  I noticed that Jason van Zyl, Leonard Flournoy, Tracy 
> Adewunmi
> and Rafal Krzewski were listed as original authors.  Are they still 
> around?
> Is there some original design notes, etc. that might be of use?

JvZ is definitely around, but very busy on lots of other projects.  I
think he's presently traveling but I'm sure he'll add to the
conversation when he gets back.  The rest I can't say.

Colin Chalmers and some of his colleagues have discussed this before on
the turbine-user list.  I remember some discussion about an LDAP schema
and DNs and such (exposing more ignorance, I know 8^).

Here's a link to the archive that should get you too the relevant thread.
http://www.mail-archive.com/turbine-
user%40jakarta.apache.org/msg02150.html
Paul Esposito's name is one this one.  I am fairly certain that nothing
ever came of this thread (or the LDAP stuff would be working now).  It
might be worth firing an email off to those two to see if they have any
time they can offer to help.  They have at least have more experience to
bring in this area.

I'm happy to lend a hand (maybe it'll give me an excuse to finally
learn LDAP and JNDI 8^).


> I'm going to cross-post this to turbine-dev since that is probably where
> this thread should be anyways.

good move.  this is definitely the right place for the conversation.


-Eric

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

RE: LDAP Authentication

[Mitchell Christensen]

Aaron,

Excellent points (and thanks for responding :) ).

Unfortunately, we are integrating our site with two third party apps which
also require user authentication.  We could maintain userid/passwords within
each app, but then pw admin becomes a nightmare (the back-end apps don't
provide an API for updating passwords).  As it turns out both of our
"back-end" apps support LDAP authentication.  This means that if a user
changes thier own password, and we go with LDAP, all three (Turbine and the
two other apps) are in sync.

As for connection pooling, I really don't see that much interraction with
the LDAP server.  At login we authenticate (bind), and that's it.  This is a
great point however, and I wish that JNDI supported pooling.  We also may be
shipping our product to companies that already authenticate using LDAP, and
we would like to simply point to their LDAP server.

Give all of this, unless someone can see something I've missed, I think I
pretty much need LDAP authentication.

Nice idea on that last point.  Any ideas on how to authenticate
programmatically within Turbine?

-Mitch

-Original Message-
From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 2:08 PM
To: Turbine Developers List; 'Turbine Users List'
Cc: Dan Sojka; Brian Reaves
Subject: RE: LDAP Authentication


Out of scope, but why are you using LDAP?  Do you already have other
applications using it?  No criticism implied.  I just want to know.

We started using LDAP at my company and just got rid of it.  It didn't
provide us with much and we had trouble pooling the connections.  It became
a password repository after a while and then we just phased it out by
storing the passwords in the database as users logged in.  After a while we
started hitting the database before LDAP to speed things up, and only going
to LDAP if the password wasn't in the db.  We didn't have nay applications
that couldn't get to the production database but could use LDAP, so it
served no purpose.  We didn't need to distribute the login load and it
didn't really help do this since there were roles and permissions and ACL
data that need to be loaded from the database for each login anyway.  So we
saved the $.25 or whatever the per user license was on LDAP.

If it is an emergency, for the time being, you can just hit LDAP using the
netscape libraries and then authenticate redundantly in Turbine using the
information pulled from LDAP, I suppose.  

Just curious.

Aaron

> -Original Message-
> From: Mitchell Christensen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 4:49 PM
> To: 'Turbine Users List'; '[EMAIL PROTECTED]'
> Cc: Dan Sojka; Brian Reaves
> Subject: RE: LDAP Authentication
> 
> Eric,
> 
> Thanks for replying.
> 
> Since my last posting I've been poking around a bit and did notice that
> LDAPSecurityService is in fact stubbed out.  As to your question.  I think
> I
> have no choice but to make it work for my project, and I'd be happy to
> contribute.  After looking at the code, I'm wondering if this shouldn't be
> implemented using the om/peer model, but that is meant solely for RDBMS
> right now (correct? Its a different discussion altogether, but why can't
> objects be mapped to LDAP as well?).  For now I was thinking about simply
> putting the JNDI calls directly in the LDAPSecurityService.
> 
> Also, the current implementation won't bind (authenticate) against
> Netscape
> Directory Server.  I understand the problem, but won't go into it here
> because it is somewhat long-winded.  There will need to be a change or two
> to the LDAPUserManager as well.
> 
> Would it be fare to ask for a brain dump from anyone who has thoughts on
> how
> this should be done in exchange for building the LDAP interface and
> submitting?  I noticed that Jason van Zyl, Leonard Flournoy, Tracy
> Adewunmi
> and Rafal Krzewski were listed as original authors.  Are they still
> around?
> Is there some original design notes, etc. that might be of use?
> 
> I know this is a lot to ask, but I'm behind schedule, and I need to get
> this
> working ASAP.
> 
> I'm going to cross-post this to turbine-dev since that is probably where
> this thread should be anyways.
> 
> Thanks,
> Mitch
> 
> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 12:03 PM
> To: Turbine Users List
> Subject: Re: LDAP Authentication
> 
> 
> On Thursday, January 31, 2002, at 08:27  AM, Mitchell Christensen wrote:
> 
> > I searched the archives and found some messages
> > from Jason van Zyl stating that LDAP authentication doesn't work.  Can
> > someone confirm/deny this?
>

RE: LDAP Authentication

[Aaron Smuts]

Out of scope, but why are you using LDAP?  Do you already have other
applications using it?  No criticism implied.  I just want to know.

We started using LDAP at my company and just got rid of it.  It didn't
provide us with much and we had trouble pooling the connections.  It became
a password repository after a while and then we just phased it out by
storing the passwords in the database as users logged in.  After a while we
started hitting the database before LDAP to speed things up, and only going
to LDAP if the password wasn't in the db.  We didn't have nay applications
that couldn't get to the production database but could use LDAP, so it
served no purpose.  We didn't need to distribute the login load and it
didn't really help do this since there were roles and permissions and ACL
data that need to be loaded from the database for each login anyway.  So we
saved the $.25 or whatever the per user license was on LDAP.

If it is an emergency, for the time being, you can just hit LDAP using the
netscape libraries and then authenticate redundantly in Turbine using the
information pulled from LDAP, I suppose.  

Just curious.

Aaron

> -Original Message-
> From: Mitchell Christensen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 4:49 PM
> To: 'Turbine Users List'; '[EMAIL PROTECTED]'
> Cc: Dan Sojka; Brian Reaves
> Subject: RE: LDAP Authentication
> 
> Eric,
> 
> Thanks for replying.
> 
> Since my last posting I've been poking around a bit and did notice that
> LDAPSecurityService is in fact stubbed out.  As to your question.  I think
> I
> have no choice but to make it work for my project, and I'd be happy to
> contribute.  After looking at the code, I'm wondering if this shouldn't be
> implemented using the om/peer model, but that is meant solely for RDBMS
> right now (correct? Its a different discussion altogether, but why can't
> objects be mapped to LDAP as well?).  For now I was thinking about simply
> putting the JNDI calls directly in the LDAPSecurityService.
> 
> Also, the current implementation won't bind (authenticate) against
> Netscape
> Directory Server.  I understand the problem, but won't go into it here
> because it is somewhat long-winded.  There will need to be a change or two
> to the LDAPUserManager as well.
> 
> Would it be fare to ask for a brain dump from anyone who has thoughts on
> how
> this should be done in exchange for building the LDAP interface and
> submitting?  I noticed that Jason van Zyl, Leonard Flournoy, Tracy
> Adewunmi
> and Rafal Krzewski were listed as original authors.  Are they still
> around?
> Is there some original design notes, etc. that might be of use?
> 
> I know this is a lot to ask, but I'm behind schedule, and I need to get
> this
> working ASAP.
> 
> I'm going to cross-post this to turbine-dev since that is probably where
> this thread should be anyways.
> 
> Thanks,
> Mitch
> 
> -Original Message-
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 01, 2002 12:03 PM
> To: Turbine Users List
> Subject: Re: LDAP Authentication
> 
> 
> On Thursday, January 31, 2002, at 08:27  AM, Mitchell Christensen wrote:
> 
> > I searched the archives and found some messages
> > from Jason van Zyl stating that LDAP authentication doesn't work.  Can
> > someone confirm/deny this?
> 
> confirmed.  LDAP stuff is broken.  Interested in volunteering to fix it?
> 
> -Eric
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-dev-
> [EMAIL PROTECTED]>

RE: LDAP Authentication

[Mitchell Christensen]

Eric,

Thanks for replying.

Since my last posting I've been poking around a bit and did notice that
LDAPSecurityService is in fact stubbed out.  As to your question.  I think I
have no choice but to make it work for my project, and I'd be happy to
contribute.  After looking at the code, I'm wondering if this shouldn't be
implemented using the om/peer model, but that is meant solely for RDBMS
right now (correct? Its a different discussion altogether, but why can't
objects be mapped to LDAP as well?).  For now I was thinking about simply
putting the JNDI calls directly in the LDAPSecurityService.

Also, the current implementation won't bind (authenticate) against Netscape
Directory Server.  I understand the problem, but won't go into it here
because it is somewhat long-winded.  There will need to be a change or two
to the LDAPUserManager as well.

Would it be fare to ask for a brain dump from anyone who has thoughts on how
this should be done in exchange for building the LDAP interface and
submitting?  I noticed that Jason van Zyl, Leonard Flournoy, Tracy Adewunmi
and Rafal Krzewski were listed as original authors.  Are they still around?
Is there some original design notes, etc. that might be of use?

I know this is a lot to ask, but I'm behind schedule, and I need to get this
working ASAP.

I'm going to cross-post this to turbine-dev since that is probably where
this thread should be anyways.

Thanks,
Mitch

-Original Message-
From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 01, 2002 12:03 PM
To: Turbine Users List
Subject: Re: LDAP Authentication


On Thursday, January 31, 2002, at 08:27  AM, Mitchell Christensen wrote:

> I searched the archives and found some messages
> from Jason van Zyl stating that LDAP authentication doesn't work.  Can
> someone confirm/deny this?

confirmed.  LDAP stuff is broken.  Interested in volunteering to fix it?

-Eric

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>