Scott Bown wrote:
We have 6 extranet applications with a few more on the way. Currently
every uses from each client shares a joint client login. We need to
separate this and have individual logins for each user at each client.
We're wanting to implement a LDAP Directory (OpenLDAP) to store User
information with the aim to using a web Single Sign On solution across the
current and future applications.
We'll store the standard user details, username, name, email, address,
phone number. But we also need to store additional attributes, clientID
and a couple of other ID's.
Use a custom schema with an auxiliary object class for accounts.
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.
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.
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.
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?
Your perception of ease is probably based more on your level of
experience or availability of supporting tools than the data management
itself, which can be easier in a directory. The real reason to consider
this separation is if the user information requires a relational model
to support drill-down queries or very high data volatility.
Thanks for any advice or links to websites with good practices for LDAP
design.
I won't presume to represent such, but since you mentioned using JLDAP
and web interfaces anyway you might want to look at this:
http://www.mentata.com/ldaphttp/
Jon Roberts
www.mentata.com
---
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.
