Re: Some questions about LiveUser

Christian Schäfer wrote:

first: we obviously need to have useraccounts with passwords. we also need to assign one-to-many roles to a user, a role being 'administrator', 'tutor', 'student' and 'guest', all basically being a set of permissions. a user assigned to more than one role must inherit all of these roles' permissions. further we need to be able to place existing users in groups called 'classes'. a class being a collection of at least one tutor, many students and maybe one or more guests. these classes gain access to certain documents and project data (this has ntohing to do with permissions). a user can be assigned to one-to-many classes. is this possible to do with LiveUser?

Hi Christian, It is if you rewrite the dictionary :-) Currently there is no entity called "role" in LiveUser. We have had more than one discussion if it should be integrated, but the perceptions what a role is and what it should do in an application differ too much - obviously, there is no real standard fore a role-based permission system, every application handles it differently. That's why we think it's best to let roles be handled by the application, not LiveUser. BUT... all that you've described can already be done using groups. You can assign a set of permissions to a group, so that would basically be your "role". Users who are assigned to a number of groups will inherit all their permission settings. "Classes" would be groups as well. In our discussions we have always concluded that there's nearly nothing you can't do with just assigning groups. Everything else is really more a question of defining new words for things that have already existed before.

second: I like the database abstraction in LiveUser using PEAR::DB. but is it possible to use PEAR::DB_ldap[2] also? we have a very hard requirement to use a local ldap server. but need to be able to replace it by any other database structure. so we want to be independant of the database solution of the user, that uses our system, but will privately be dependant on ldap. further more we will be using two ldap server. one being local with total control, the second being external. accounts of the second will be aliased on the local one. so the ldap implementation must be able to handle ldap aliases. is this entirely possible?

It's not possible to use DB_ldap with the existing LiveUser containers, as they all send normal SQL queries to DB, which LDAP won't understand. However, if you have some experience with LDAP (unfortunately we don't), it should be very very easy to make a new container that makes use of DB_ldap and do what you want. If you need help with how to write a new LiveUser container, I'll be happy to answer any questions you might have. Once such a container exists, it'll be very easy to switch back and forth between LDAP- and RDBMS-based containers, or even use them both at the same time - it's all a matter of changing the configuation array, then. Being able to use more than one server for authentication was one of the primary design goals of LiveUser and thus is very much possible - although I don't think I've fully understood what you mean by "accounts of the second will be aliased on the local one"... When using LiveUser, all user accounts exist separately in the configured auth containers (servers). When adding a user, you must define a user-mapping for the permission container, so that it will know what permissions a certain user from a certain auth container will have. So the "aliasing" is basically done by LiveUser... if that's what you mean. CU Markus