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

[Petr Viktorin]

On 02/13/2013 04:15 PM, Petr Spacek wrote:
> On 13.2.2013 15:53, Simo Sorce wrote:
>> Hello list,
>>
>> with recently seen a few requests to add FreeIPA users via LDAP
>> directly. This is a common method supported by many meta-directory/HR
>> systems, however so far we cannot really recommend it because we add
>> quite a number of attributes automatically in our framework code when we
>> create users, and those functions can change in future versions.
>>
>> However these external tools are usually not very flexible and
>> supporting them as they are would make for a much better experience for
>> integrators.
>>
>> I had a brief discussion with Rob on IRC on how to address this
>> situation.
>>
>> If we limit ourselves to users we could probably resolve this problem
>> with a relatively simple 389ds plugin that intercept add operations that
>> try to add a user.
>>
>> The idea is that the remote system would be allowed to set a minimum of
>> attributes (even incomplete according to our schema). But as long as a
>> specific set of objectclasses is set (say person and posixaccount) the
>> operation would be recognized as an attempt to create a user account.
>>
>> In this case the plugin would take over the operation and perform a call
>> against our framework using json. The call would send a reformatted
>> request using the data we got in input so that any custom
>> objectclass /attribute can be preserved. The call would also add a
>> special flag so the framework knows this is coming from 389ds itself.
>>
>> The framework would treat this requests in a slightly special way, it
>> would use all the common code currently used to properly format a user
>> entry adding all the ancillary data we need, but instead of trying to
>> ldapadd the entry, it would instead return it back to the caller.
>>
>> 389ds at this point gets back a json reply, convert it into an ldap add
>> operation and proceeds with this new 'augmented' operation instead of
>> the original one.
>>
>> What do people think about this option ?
>> I think it would be extremely valuable for admins, as it would allow
>> them to drive user 'synchronization' in a very simple way.
>> It could also be used to properly augment winsync users so we can allow
>> full creation when syncing from AD with all the proper attributes
>> created through the json request. So I see a lot of optential here.
>>
>> The only doubt is the json back and forth communication.
>>
>> What do people on the framework side think ? Is there going to be any
>> big problem in adapting the framework so we can use common code to
>> prepare the object but then change the last stp and return a json reply
>> instead of perfroming an ldap add operation ?
>
> Personally, I don't like the idea of JSON requests & response parsing
> *inside* 389. I see a lot of opportunities for crash or security hole.

It seems Petr is reading my mind here. I was thinking about these 
solutions too; they seem cleaner but I don't know if they're feasible.

> What about small (optional) separate daemon?
>
> A) Variant with separate sub-tree
>
> 1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com
> 2. watch this sub-tree with persistent search
> 3. catch new objects and run IPA commands as necessary
> 4. replace "old" objects with referrals to IPA objects (or do something
> different)
>
> I'm not sure that various meta-directory systems can handle situation
> where user disappeared/object is moved/object is morphed to referal.
> That can be a problem.

A separate tree would mean we're not committed to supporting this 
particular kind of magic forever. We could have different "compatibility 
hacks" in the future, each with its own semantics.


> B) More crazy variant with LDAP "proxy"
> (Now I'm on very thin ice, I don't know how complex it would be. I only
> found some examples like [1].)
> Prepare "fake" (non-IPA) LDAP server with same LDAP "structure" and let
> separate daemon watch server's content and run IPA commands as
> necessary. It would be best if the small daemon can pretend to be LDAP
> server and catch LDAP operations directly, as shown in [1].

An adaptor would certainly be the proper solution when we need to 
interop with an inflexible foreign interface. The question is if 
building one is worth it.



In both cases rather than core IPA functionality this would be something 
external, something the users have to explicitly install and use, 
something that doesn't necessarily have to work right with user-supplied 
plugins, something limited (say, to  users only), and something that'd 
always use existing code paths.
I'm really worried about scope creep here; after a few years of adding 
features like this IPA would become unmaintainable. Better to have a 
focused core and add on top.

-- 
Petr³