On 8/16/07, Felix Schwarz <[EMAIL PROTECTED]> wrote: > > Mike Orr schrieb: > > On 8/15/07, Neil Blakey-Milner <[EMAIL PROTECTED]> wrote: > >> Another possible requirement is that some users will have their > >> authentication details (ie, password) come from one system (say, a > >> particular LDAP server), and others from another (say, the password in > >> the database). Either way, the user data probably should be kept in > >> the database. > > > > That may not be possible. The LDAP may contain five thousand > > potential users, and you aren't informed when one is added or changed. > > I agree: User data (id and password) should stay where they are. The > application > may decide to store additional information (such as application specific > preferences for a user) in its own database. Groups are a bit more complicated > though: Sometimes the groups can be found where the authentication data is > (LDAP) but an application may want to define new groups which can't be > propagated in the main directory. So we need to support a mixture of both.
If you're _only_ ever getting all your identity, authentication, and authorisation information from LDAP, then life is sweet. But I think that's a fairly uncommon case, actually - your group information, your permissions, your internal project role data, and so forth needs to interact with something more. I'm not saying it's a row from a database, but that's certainly what we need to allow to be sufficient for it. To make it possible to implement it as such. Since, I imagine, it'll be the sane default for such things. People will need to say that Person X created this piece of content, or wrote this comment. Updating the database data at login from the LDAP data is simple enough - that's worked on both the systems that I've developed that do that. And creating the users automatically when they first log in using their LDAP data is also simple enough. Although we should put some thought into how to force someone to (at the discretion of the application) provide additional sign-up data. The same pattern applies to OpenID, and I suspect CAS, and both of these don't provide enough capability to read application-specific group and permission data at the best of times. Think of the university department that is required by the university administration to use CAS - they don't have any particular control over the groups in the system. Same applies to departments of large corporates (which is where my previous project is squarely aimed at, and doing well at) - they use LDAP to reduce username/password combinations, but they're not buddies with the sysadmins to be able to store the data they need in there. The question is not what is built into the system, but whether the system allows for these fairly common requirements easily. Can I easily pull authentication for users "x" and "y" from sources "a" (LDAP) and "b" (database table "users") (by providing my own implementation that uses the system built-in authentication for source "a", and my own implementation for source "b"). If, the user came from "a" (LDAP), can I, easily get authorization information from source "g" (database tables "groups", "permissions", "user_groups", ...). Neil -- Neil Blakey-Milner http://nxsy.org/ [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
