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

[Simo Sorce]

On Wed, 2013-02-13 at 08:08 -0700, Rich Megginson wrote:
> On 02/13/2013 07:53 AM, 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.
> 
> So the 389 plugin would make an http/json call to the framework?

This i the idea.

1. add operation comes in
   For example:
	dn: uid=foo,cn=users,cn=accounts,dc=freeipa,dc=org
	changetype: add
	objectclass: ipa-add-user
	objectclass: custom-stuff
	uid: foo
	custom-attr: bar
	... (other attributes we require absolutely)
2. we match on special objectclass 'IPA-ADD-USER'
3. plugin converts incoming entry into json request and calls framework
4. framework does magic and creates a full ldap request
5. framework converts it back into a json object
6. plugin converts json object into an add request and replaces the
original add with the new data
7. plugins tries to commit the new data as the original user.
8. if there are any errors they are sent back to the client.

This plugin would need to operate before any other so that all other
plugins will see the data as modified by the call to the framework, not
the original request.

Also the special objectclass is just an idea, I am open to other
suggestions. The only important thing is that we have a way to
distinguish between an complete add operation that should just go
thorough and a an add operation that needs to be sent to the framework
for adjustment. We could also decide to always intercept, but it seem to
be a bit wasteful for regular framework add operations as it would go
through it twice: http -> framewrok -> ldap add -> framework (recheck)
-> add


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York