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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to