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

[Rob Crittenden]

Simo Sorce wrote:
> On Thu, 2013-02-14 at 09:47 -0500, Rob Crittenden wrote:
>> 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).
>
> I did, please see my other emails in the thread.
>
>> 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.
>
> We do not intercept mods, period.
> The only *real* issue is creating users, because the framework adds a
> lot of stuff to properly format users, but modifications from LDAP
> clients is fair game.

We are in agreement here. My point is that if we try to write to a 
special part of the tree then move the entry then MODS will always fail.

> We cannot consider the framework as the only gatekeeper beyond object
> creation, if this is not clear we need to discuss.

That was actually the point of the framework from the beginning.

>> And of course this leads into deletes. We want users gone when they
>> leave the company. Feature creep already.
>
> Do we do anything special in the framework for user deletes now ?
> I am not aware of any special ops, and I would be against making a
> delete operation a special operation.

Any operation can have a pre/post operation. One RFE we have is to add 
triggers so that shell scripts (or whatever) can be executed at times. 
This is is the sort of thing that would be missed.

>
>>    > 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, ...
>
> Yes, this is the only concern, I made one proposal to avoid the issue,
> there are also other ways, for example the framework could use a special
> control to tell our server 'I am the framework, do not loop'. We just
> need to decide what's the best way to do it.

Right. I don't know enough about how much flexibility these external 
systems have when creating LDAP objects so they may not be able to add 
additional objectclasses. A control may be the way to go.

> For example we already need to avoid any interference with replication,
> but that is easy to do, as we know if an operation is coming via
> replication. The other is winsync, but I would argue that winsync maybe
> should actually use this plugin as it would make it more consistent with
> the framework.

Yes, if we could solve this without too much performance issues that 
should work.

rob