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]>
