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