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

[Simo Sorce]

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 cannot consider the framework as the only gatekeeper beyond object
creation, if this is not clear we need to discuss.

> 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.

>   > 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.

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York