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

[Rob Crittenden]

Petr Viktorin wrote:
> On 02/13/2013 03:53 PM, 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.
>
> Why return the data as JSON, instead of writing it directly to LDAP?
> Our own post-callback assumes the user is already in LDAP, and who knows
> what user-supplied callbacks will do. Keep in mind IPA is plugable; at
> least for outside plugins' sake (if not our own sanity's) we should keep
> the number of code paths to a minimum.

Simo's concern was, I believe, with permissions.

My concern is with moving the logic of adding users directly into 389-ds.

I think Simo's concern was with the credentials used to add the user. 
His idea was to use the 389-ds service principal to call into JSON. This 
principal normally does not have user add permission but if all we were 
doing is determining what the add should look it it should be adequate.

Then the formatted user would be returned and 389-ds base would attempt 
the ADD, authenticated as the user who did the BIND (which we probably 
need to assume is a simple bind).

Otherwise we will need to find some way to connect to the framework, 
authenticate as the user who made the 389-ds BIND, and add the user.

rob