[Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP

[Rob Crittenden]

John Dennis wrote:
> On 02/14/2013 09:05 AM, Simo Sorce wrote:
>> So as I proposed we can call ipa user-add from LDAP from a
>> non-transactional pre-op plugin. We just need to be careful about when
>> we allow that to avoid loops, but besides that problem it seem
>> relatively easy and does not require crazy things like playgrounds or
>> even full LDAP proxies.
>
> I think I need a clarification because perhaps I didn't fully understand
> your proposal.
>
> Is the idea with a non-transactional pre-op plugin it invokes user-add
> and then the pre-op returns *without* having modified ldap? In effect it
> acts as a trigger?
>
> That still implies there has to be a separate tree where the foreign
> entity writes (and the pre-op plugin watches) because otherwise how
> could the pre-op plugin distinguish between framework writes and foreign
> writes?

The proposal is that we write a 389-ds plugin that intercepts LDAP ADD 
operations. I don't think Simo proposed where in the tree this would be 
written, or whether we would be able to distinguish between a normal ADD 
and this special case (loop 1).

For the purposes of modification you probably want it to write into the 
current user container. It will need to be able to push MOD requests for 
names, addresses, etc. Most LDAP apps take a single basedn against which 
to do things. We can't expect to be able to provide one set for adds and 
one set for mods.

And of course this leads into deletes. We want users gone when they 
leave the company. Feature creep already.

  > If there is a separate tree where is the looping issue? You still
> haven't explained this.

The looping is in telling whether the add is from the external HR source 
or a "normal" ADD from IPA. If we get it wrong, ever, then it will ADD, 
then call ipa user-add, ADD, call ipa user-add, ADD, ...

> Also, under the scenario that a foreign entity writes something into
> LDAP (somewhere) and it triggers us to call user-add via some mechanism
> then what happens when errors occur? The foreign entity will not know we
> rejected the operation nor why.

I don't know about that. We'd get the exceptions back from JSON so would 
have to translate them back into LDAP errors. For the cases there isn't 
a 1-1 match we'd have to do our best and add good logging.

> Also, don't forget they want to delete users, remove group membership,
> add group membership, add groups, remove groups etc. Some of these
> operations are dependent upon logic in our framework. I don't see how
> some of these operations can be reliably managed by a foreign entity
> simultaneously performing LDAP operations.

Yup, we're on the same page here.

rob