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

[John Dennis]

On 02/14/2013 12:16 AM, Nathan Kinder wrote:
> 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.

Yes, this is exactly what I'm saying and we concur.


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/