On Thu, 2013-02-14 at 09:33 -0500, 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 idea I flaunted around is that the pluggin triggers only if a
special objectclass is used. The framewrok would never try to create a
user with this special objectclass so loops are avoided.

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

No separate tree, the plugin intercepts the Add operations, and calls
the framework. The framework does the real user creation and then
returns. At that point the pre-op plugin returns immediately with the
error code from the framework discarding the actual add operation.

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

We return back an error.

> The foreign entity will not know we rejected the operation nor why.

This is the problem if you use a staged approach, and one of the reasons
I do not consider it as viable, and therefore reject any proposal that
imply staged writes and separate operations.

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

Which ones. Only user creation is really special.
Deleting a user should not depend on the framework, nor adding group
Adding a user is a special case, and should be limited to that.

> I don't see how 
> some of these operations can be reliably managed by a foreign entity 
> simultaneously performing LDAP operations.

I do not see what your concerns are.


Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to