On Wed, 2013-02-13 at 18:11 +0100, Petr Viktorin wrote: > >>> 1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com > > > > This has more consequences than you may think. > > I do not like the separate field idea because you need to treat it in a > > special way. We would probably need special ACIs to anoty allow any > > other client to see this subtree otherwise they may see incomplete > > objects. Yet we need to allow some user to write to it. > > We need to decide case by case which plugins to enable, not all DS > > plugins can use filters or exclude subtrees so we may have issues with > > some plugins if we do not want them to operate on these special entries > > and so on. > > Is it possible to use read ACIs of the original tree?
Not sure what's the question here. Care to elaborate ? > The problem is that the framework may do more than LDAP operations. It > supports user-written plugins that can literally do anything. > We'd need to limit what IPA plugins can do, or how they do it, otherwise > it's impossible to just return the result. Ok, then maybe we can have a 'core' common logic part that has some more limitations. > So I can see a DS plugin calling IPA, but IPA really has to write the > results itself. This is harder, but could be done too. The way it would work would be to make 389ds able to perform s4u2self for the case a user bound to LDAP with a simple bind, and then s4u2proxy with the evidence ticket to get HTTP/server ticket, then we can connect to the framework using the user's identity. In turn the framework will perform an additional s4u2proxy delegation to get a ticket back to ldap/server to perform the add operation. This means the flow would be: client --(LDAP)--> 389DS --(HTTP/json)--> framework --(LDAP)--> add The problem with this solution is that there is a risk of loops, so we need a mechanism that makes it impossible for the 389ds plugin to recurse into the framework. Also we need to make sure the add operation is not blocking add operations by keeping a transaction open causing a deadlock. And we cannot do that by immediately returning to the client because we need to wait for the framework reply to know if the operation was successful or not. I see some more low level risks doing it this way which is why I made my proposal to avoid this potential loop. Rich, is there potential from deadlocking here due to the new transaction stuff ? Or can we single out this plugin to run before *any* transaction is started ? > > I do not see this as a slippery slope, as it would be limited to user > > creation by definition. > > I'd be extremely surprised if all of these inflexible external HR > systems happened to limit themselves to user creation. HR systems only deal with hiring and firing employees, they *may* deal with adding users to groups, but that doesn't require special operations for us, it is just a matter of adding a 'member' attribute to a group object. I do not think we need to offer anything else here. We already have proof this is sufficient, because we have experience with the AD winsync plugin which has a similar function, the only differnce is that the driver is an AD server instead of an HR system directly. And with that plugin we also only create users by default, and we haven't heard many requests to do anything more. The only request we really had was to make sure we could sync also posix attrs from AD, but that's it, still just basic user info. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
