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

[Nathan Kinder]

On 02/13/2013 08:30 PM, John Dennis wrote:
> On 02/13/2013 10:40 PM, Nathan Kinder wrote:
>> With the DS plug-in approach that calls into the IPA framework with a
>> 'mock add' to form the resulting entry at the pre-op stage, we could
>> take care of the initial ADD operation of the user entry.  We would
>> still need to have a way to trigger the additional write operations that
>> the IPA framework performs.  The proposed DS plug-in could do an
>> internal search operation after the add, then it could perform the
>> additional write operations that are needed.  This logic would need to
>> be in the DS plug-in, or we would need another way to get the details
>> from the IPA framework via JSON.  The approach begins to get a bit 
>> messy.
>
> Messy is one word for it :-) Herein lies the problem. user-add is 
> actually a simple case where in this particular version of our code we 
> know the LDAP operations that occur and in what order. But there is 
> nothing in our coding guidelines that guarantees this, it just happens 
> to be true today. Pre and post callbacks are free to do as they 
> please. The logic in our ldap module can change (in fact it's 
> undergoing a rewrite as we speak). We've committed to supporting an 
> extension mechanism (plugins) that ties into the framework operations 
> and who knows what might occur in that code. At the moment it's not 
> used, but hopefully it will be.
>
> Then comes the question, where do we draw the line? Do we say only 
> user-add with no additional options is supported because we know what 
> occurs during it's processing and hence we feel safe emulating 
> user-add outside the framework?
>
> We all know this is a slippery slope, as soon as you support user-add 
> this way we'll be getting requests to support other commands or other 
> options. And after we make framework changes (which we do frequently) 
> are we going to test these out-of-band operations continue to emulate 
> the ever changing framework?
>
> It's a slippery slope that can expose us to problems we don't need.
>
> Jenny, do you want to test an entirely different mechanism or do you 
> want to limit it to our defined API?
>
> We have a defined API, I really think that's the only thing we should 
> support. Backdoor shortcuts that sidestep our framework should be off 
> the table IMHO, it's just inviting too many problems. 
This is why I think that the most sane approach is to put something in 
front of 'ipa user-add'.  This is not without it's own set of 
difficulties, but if we need a basic LDAP interface that can be used to 
create IPA users, it should end up calling into the same code that 'ipa 
user-add' uses.  This would ensure that any extensions (plugins) for the 
framework are called.

I actually see this as very similar to the LDAP migration case.  For 
migration, we basically take entries in LDIF format, extract the 
relevant data, then feed it into 'ipa user-add', right?  That's more or 
less what we need to do here for HR systems that provision users, but 
the user addition needs to be pushed to IPA via an LDAP client instead 
of IPA pulling from an LDAP server.
>
>