Al, I'm glad you like the idea :). One of my personal pet peeves is the lack of LDAP support for user management in a lot of opensource products, so I'm hoping I can help remedy that a little.
> I think one has to consider what the benefits of using LDAP are as a user > store? I would have thought the main benefit is centralisation, single > sign in that sort of thing. Well, my reason for needing LDAP as the user store is that's where all 15,000+ of my user accounts are :). It has been very useful for single-sign on. We use a bunch of Novell products so our workstations authenticate directly to NDS for user logins and our webapps use eDirectory (Novell's LDAP server) for authentication using the same credentials. We also use ActiveDirectory for a few things (Citrix, mostly) that can't talk to LDAP directly and we have some tools that replicate changes in NDS to AD to keep them in sync. > In doing that one would need to use a common > schema that all apps authenticating users etc.. would all support I have > No real experience with LDAP schema's but I guess the trick here is to use > a recognised schema for users and add the extra nodes that slide would > require, remembering that ACLs are quite complicated in slide, would these > apply outside of slide?? or would each app using LDAP have its own > application specific ACLs I definitley find the ACLs difficult to get my > head around. Having a common schema isn't necessary as long as you're only talking about authentication. The best, and most cross-implementation authentication solution is to have LDAP server handle all the authentication. Rather than fetching a username/password pair from LDAP and comparing them in the application you just attempt to bind to the LDAP server using the user's credentials. If the bind is successful then the username/password is correct. This is actually the only way to authenticate with eDirectory since for security reasons it's impossible to retrieve a user's password. Talking about ACLs gets really sticky. As far as I know every LDAP server has it's own unique way of managing authorizations internally. Since LDAP is just a communication protocol I don't think it has any specifications for this, so I don't know of any standard way to get/set access permissions on objects in an LDAP server. This makes managing ACLs through Slide rather difficult. I see three approaches to this: 1) Slide has a very permissive ACL for every object in the LDAP store, basically handing all authorizations off to the LDAP server. 2) Slide connects to the LDAP server as an "admin" user then manages ACLs internally to control access. This has some possible security and auditing complications, though. 3) LDAP is read only. All management is done externally to Slide. This works for users and groups but really limits LDAP as a general purpose Store. The other thing to consider is how to handle Slide-specific attributes on objects. All objects in LDAP have one or more "objectClass" attributes that determine which properties are available on the object. Extending the LDAP schema with a new Slide objectClass is doable but not always feasible (I would have a hard time getting our LDAP admin to do that, for instance). This means Slide will need to support storing extended properties locally in addition to the properties stored in LDAP. I was thinking of maybe extending the tx store and mapping which properties should be stored where. > Actually the text stores are probably better to look at than the SQL/J2EE > stores as they are more node like (albeit xml node based), LDAP dI think > has a node like structure so the match is good. I think I agree with this. The only thing is the tx store is a bit more complicated (I'm still trying to get an understanding of how Stores work) and I think the tx store caches a lot of information to help speed up performance. The caching is making replication a real pain at the moment, so much so that I had to implement the first phase of my project using Tomcat's webdav servlet with some simple filesystem replication. Whatever stores I end up using they need to play nicely in a cluster and it looks like the SQL stores might handle that better at the moment than the tx store. > The other question would be how would you talk to LDAP, would you use JNDI > or specific LDAP libraries ? JNDI. It's all I've used and I see no reason to switch now :). > I think JNDI may have a benefit here, plus > slide could also benefit from a little JNDI support, again these are not > areas of my expertese, just my $0.02, and I would certainly be prepared to > help as long as the code was contributed back (I.E opensourced). I'll have to check with my boss about licensing, but we're not a software company so I really hope there aren't any problems there. I'm hoping I can contribute everything back since what I'm working on is likely to be fairly extensive. I'll let you know on this. James Mason Adventist Health Programmer/Analyst 916.783.2576 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
