[dev] Auth drivers and configurable capabilities, ldap groups hierarchy

[Jan Schneider]

Zitat von Lukas Macura <macura at opf.slu.cz>:

>
> Hi to all,
>
> I am new to this list so I would introduce me and our scenario. We use
> Horde on our university long time, more than three years. Most used is
> IMP but we would want to convert it from mail client to intranet. In
> fact, some users already uses it but we want let all students and
> employee uses our system.
>
> First of all, thank you very much for code, it works and we are happy
> that we can use it. It would be much more complicated for us to use
> standalone mail clients.
>
> But we have to solve some problems now and I want to discuss it here.
>
> First, I think it would be good to be able to change capabilities od
> auth driver. I already posted it as enhancement but it was rejected.
> Maybe it is my mistake because I should discuss it here and explain. So
> I am doing it now.
>
> Especially in our setup, horde is only intranet application which is
> connected to LDAP. NOT MANAGEMENT application to modify/delete users and
> group, I know that only administrators can do this actions, but we have
> more administrators, which can do some IMP and IMAP manipulations etc
> but they do not need to do anything with users. More precisely, we have
> to be sure, that there will be no change in LDAP made from Horde.
>
> I think that capabilities could be ANDed with configuration options.
> In LDAP backend, there is something like:
>
>    var $capabilities = array('add'           => true,
>                               'update'        => true,
>                               'resetpassword' => false,
>                               'remove'        => true,
>                               'list'          => true,
>                               'transparent'   => false);
>
> and it is hardcoded. But if I could change it in config, it will help
> us. Because I will be sure that nobody can make change to LDAP tree if I
> have in config:
>
> $conf['auth']['params']['capability'] = Array ('list','modify');
> Patch is trivial, I can post it but I want to discuss it first here.
> Rejected ticket is here: http://bugs.horde.org/ticket/8293

I already expressed my thoughts when rejecting that ticket, so I'll  
leave to other developers/maintainers/administrators to chime in. If  
others could see this being a useful addition, I could be conviced.
I think that in a long term, this should be solved by an improved  
policy system, like partly outlined for Horde 4 already. This way  
policies could define which users had access to individual  
administration tasks.

> Next, we need to solve problems with LDAPg groups. In latest version,
> there is bug (or feature? ) ;) that we can see groups only from one
> context. Not from subcontexts. Problem is in Group/ldap.php where ldap
> drivers expects hierarchi al group tree but "forget" that to see parent
> groups, we need to interpret ous as groups. I found, that it probably
> worked some time ago, but was rollbacked at
> http://cvs.horde.org/co.php/framework/Group/Group/ldap.php?r=1.28
> Am I right?
>
> I made small patch  for Group/ldap.php which enables to see all LDAP
> groups as flat groups without hierarchy when config option 'flat_ldap'
> is true. So now we can see all groups from entire LDAP tree and it is
> partialy solved. It is trivial patch, I can post it but I would want to
> discuss if it is right way to implement LDAP groups or if it will be
> hierarchical again.

They should work hierarchically again IMO. Please test if this is a  
problem with the LDAP groups driver, or with the way we use the groups  
API. As Ben mentioned in that commit message, using colons as group  
separators (like the datatree driver) doesn't make any sense for other  
drivers. LDAP has it's own way of creating hierarchies, the group  
driver should use that, and anything inside Horde should solely use  
the group API to display and manage group hierarchies.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090529/fc2dfe80/attachment.bin>