> > When new clients are added to backend database, using JLDAP we were > > planning to generate a 'kind of' super user in the LDAP directory and > > allow them via web frontend to create users under themselves. Theses sub > > users would only be able to access the same applications as the super > > user. The idea is to push the burden of user management onto the client. > > Q1) Does that sound a sensible thing to do with LDAP? Or would using a > > database table be more effective? > It's completely sensible to address these requirements with LDAP, > however I would reconsider the described "superuser" approach. It sounds > like you are implying organizing your accounts in a hierarchy, which may > help a little with access control but can introduce further > complications in general user management. It usually makes sense to put > all users in a single place and manage access controls through groups or > attributes.
Ditto. superuser == bad; it is a pain in UNIX, don't recreate past errors just because people are familiar with them. Use role based privilege delegation. > > We would like to implement access control, so the client super user can > > say user1 can access application 1 but not application 2 and application > > 3. I was thinking having attributes on each user something like > > accessApp1=Y, accessApp1=N,accessApp1=N. Then checking for the attribute > > when user attempts login. > > Q2) is there a better way to implement customized access control. I > > thought about user groups but thought i'd have to create a new group every > > time I added a new application. > Peter's response answers this well. If you only have 6-10 applications, > the group approach isn't bad at all, plus your application "superuser" > role can be assigned to individuals through the use of each group's > owner attribute and a simple access control statement. Use groups. > The multivalued attribute approach can work well too, but it is nice to > see an application's user population in a single entry vs. a search > result; individual users often already know what they have access to. > Besides, access control for different administrators over the same user > attribute would be problematic. Yep. My advice is don't think about how the directory itself stores/presents information in terms of how easy/hard management is ["Groups are hard to deal with", etc... ] Your front end application should take care of that for you. And if you use good OO techniques... > > My colleague suggested having the user information data stored in a > > separate database and just use LDAP for username and password information. > > Personally I think this adds another layer of complexity to the solution. > > However manipulating the data in a database is easier than in the LDAP > > directory. > > Q3) Anyone have any opinions on this? I think "adds another layer of complexity" is spot on. The real question is do you need "another layer of complexity". Sometimes "another layer of complexity" is perfectly legitimate.
signature.asc
Description: This is a digitally signed message part
--- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
