> > > 1. How does the group see Ldap fitting into Turbine as a whole and the > > security in particular? > > The main application we would use at work would > be authentication. Could be as minimal as login > password, first and last names. Many of our > clients want to be able to reuse their existing > Active Directory, or other authentication service. > As opposed to maintaining duplicate sets of users > and their credentials.
I agree. We (at the company I work for) try to promote the idea of having the directory as central/leading within the organisation (ie in combination with meta solutions). So it is in my own advantage to get this to work so that I can use Turbine for other apps. > > > > 2. Should it be possible to use both a database & Ldap backend at the > > same > > time? > > Yes. > > In our application, we would need to be able to > put extended user information into our database. > We would authenticate against the LDAP server > and we'd keep a UserProfile table in the database > to store data that's not in the existing LDAP > server. I haven't given this a lot of thought, > but I think this might imply storing the roles > and permissions in the database. For our use > case, I would like to assume that the client will > grant our application only read access. > The problem (or advantage :-) ) with Ldap is that if you start thinking up your own combinations of user data you may have to change the ldap schema to accomdate that. A couple of colleagues of mine (Frank Nolden/Walter Hoogeveen) did submit a proposal last year as to how a default schema could be altered to accomodate the basic Turbine functionality of roles etc. I shall be delving into this again the coming days to see if it's still valid. Only read access? Don't you want to change password/email?? > > > > 3. Should we look into pooling for Ldap access? Not sure if that's > > possible > > with JNDI. but Netscape has an api where's it's (Pool) already built in. > > no opinion here. I don't know enough about LDAP > administration to know if pooling is necessary or > possible. Just like databases it takes time to build up a ldap connection. This could be helped by utilising a Pool. BUT unless only used in read mode one has to bind as a specific user; either yourself or as someone with enough rights to perform the actions required. The latter could also be seen as security leak. > > > > 4. Should we look at integrating Ldap Objects into Criteria similiar to > > how > > a query is built up when using a database? > > This will be necessary in order to make an LDAP > implementation of the SecurityService. But I > think Criteria is pretty biased towards database > queries. Agreed , I was thinking of trying out a few things like having a specific Ldap Criteria object. If that works then looking at how to merge with present code. /Colin > > > Thanks for looking into 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]>
