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

[Petr Viktorin]

On 02/13/2013 05:27 PM, Simo Sorce wrote:
[...]
>
> I am sorry, but 'cleaner' is really the last word I'd use, 'hack' is
> what comes to mind here to be honest.

Then I'm missing something. Thanks for your explanations.

>>> What about small (optional) separate daemon?
>
> One more moving part one additional process, that does very little, it
> looks to me as a big hammer to yield.
>
>>> A) Variant with separate sub-tree
>>>
>>> 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?

>>> 2. watch this sub-tree with persistent search
>
> Persistent search are scarce, and user creation is rare, it would be
> over blown, plus it would be a race condition if the daemon dies for
> whatever reason.
>
>>> 3. catch new objects and run IPA commands as necessary
>
> With what user identity ?
> Keep in mind that one of the reasons we use delegation is to make sure
> that ACIs are meaningful *and* auditing reflects the actual user that
> did operations.

Thanks. Now your proposal starts making sense to me.

[...]
>
>> 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.
>
> This is why I proposed a plugin that is limited to users and calls the
> framework so we can use common code.
> The *simpler* way would be to simply replicate the core framework login
> in the 389ds plugin or even *move* it there.
>
> But we want to keep the logic in the framework as it is more flexible
> and easier to work with and extend, so I proposed a 389ds plugin that
> just *asks* the framwrok for the data. This keeps the busienss loginc in
> the python framewrok, yet it allows an LDAP driver to add users properly
> in IPA just using LDAP calls.

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.

So I can see a DS plugin calling IPA, but IPA really has to write the 
results itself.

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


-- 
Petr³