in reply to Re: Access control problem
in thread Access control problem

Note that
  1. There is no problem with auth. It works quite well. The real problem is autz.
  2. When I'm generating 'modify user preferences' dialog on front-end I want to include 'Change passoword' button if and only if a user can change that password. And how can I know if user 'foo' can change password for user 'bar'? User foo is maybe an admin, and he can. But application does not know this and does not know whether to display 'change password' button or not. The only how to resolve it is to change a password, and I definitely do not want to do this in dialog generation (not dialog processing) phase.
  3. Overhead. Imagine Customer object in LDAP. There are billing information, sales information, and admin information in this single object. I want different users to have access to different parts of this object. I want to display changable fields as real inputs and read-only fields as normal non-editable text. If I would try to change every possible attribute in LDAP prior to displaying a simple HTML INPUT, it will take years to complete a single request. (Remember, LDAP is read optimized, writes are sloooow).

Replies are listed 'Best First'.
Re: Re: Re: Access control problem
by Fastolfe (Vicar) on Dec 21, 2001 at 18:14 UTC

    So let me get this straight: you want users to be able to modify LDAP data directly and you want a nice easy web interface to do the same, with consistent validation and access requirements?

    So right off the bat, you have to implement ACI's in LDAP. There's no way around that if you want direct LDAP access. The trick is exploring those ACI's to provide a meaningful user interface, right? I don't know of any way to do this in LDAP, but others might. This was probably your original question, so I apologize for not picking up on that.

    With respects to overhead, there are certain optimizations you can do, such as checking to see if the value given differs from the value stored before attempting to change it, etc. Do you expect to be doing a lot of updates such that time is a factor? If so, perhaps LDAP isn't the best choice here. A real relational database might be acceptable, but practicality may require you to push your access control into your application (though I think most if not everything can be done in a decent database package, even if it's cumbersome), which means you don't want users to directly update their stuff. If you wanted to keep a read-only LDAP copy, you could do that and update it at intervals.

    I believe that ACI's can be fetched from the LDAP server, and though I alluded to it in my previous post, I believe ACI's are also standard across most LDAP platforms. So in theory, you should be able to fetch them and parse them locally and use that information to determine whether or not the user can edit that piece of entry. Sounds daunting, I know. It would be great if LDAP has a "can a user do this" operation, and maybe it does; I don't know.