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

[Simo Sorce]

On Fri, 2013-02-15 at 17:28 -0500, Dmitri Pal wrote:
> On 02/14/2013 12:33 PM, Endi Sukma Dewata wrote:
> > On 2/14/2013 8:06 AM, Simo Sorce wrote:
> >> On Thu, 2013-02-14 at 14:26 +0100, Petr Spacek wrote:
> >>
> >>> In my Fedora 17 I found package python-ldaptor. It seems to offer
> >>> nice support
> >>> for writing own event-based LDAP servers. For simple LDAP proxy it
> >>> could be
> >>> enough.
> >>>
> >>> $ yum install python-ldaptor
> >>> $ python
> >>> import ldaptor.protocols.ldap.ldapserver
> >>> help(ldaptor.protocols.ldap.ldapserver)
> >>
> >> No.
> >> LDAP proxies are *not* simple.
> >>
> >> Ask Endi he's worked on a meta-directory for years.
> >>
> >> Simo.
> >
> > It depends on what you want to do with the proxy. If it's only a thin
> > layer which converts the LDAP ADD to IPA user-add it might not be that
> > complicated.
> >
> > Penrose virtual directory consists of a frontend LDAP interface, a
> > transformation engine, and backends which may include an LDAP server
> > as well. The front-end LDAP interface is the proxy we're talking about
> > here, it's only used to receive LDAP requests and pass them to the
> > transformation engine.
> >
> > The transformation engine is where the complexity occurs. In IPA this
> > is already handled by the framework. In Penrose it's quite complex
> > because it aims to provide a generic way to map an LDAP request to
> > multiple backends which involves dealing with different types of
> > backends, joining the backends, transforming the DN & attributes back
> > and forth, etc.
> >
> > So I'd say implementing an LDAP frontend for IPA using Python is
> > something worth exploring. That way it can run in the same process so
> > there's no concern about JSON performance/stability.
> >
> +1 I would rather go this way.
> 
> Simo,
> 
> Your point about how things should have been bight be righteous but Petr
> confusion about the role framework shows the reality. Currently all
> framework is developed as if it is the primary interface for
> creation/modification. LDAP is exposed but can be consumed by external
> clients as read only. This is how we decided to implement things. I
> clearly remember a lengthy discussion about this 4 years ago when the
> framework architecture was discussed. The main reason is plugability.
> Since we need to provide extensible plugability framework it is the only
> supportable option. For good or for bad it is how things are now and
> Petr is correct because this is what was decided and this is what he was
> told. It might have been a wrong decision (the interaction with the DS
> team was not at the same level as it is now) but under circumstances it
> was the one we made. And we now need to live with it. I do not think we
> have time to reevaluate things and move them into DS plugins is we find
> the framework abusing its power.
> 
> I generally disagree with the notion that we can and should view
> add-user as the only special operation. Because of the framework
> extensibility any operation can be special.

I do not have time to explain why I do not agree with your analysis
here. I just don't, I think I will re-raise this later.

> So I think that external LDAP proxy makes more sense. It is a bit more
> complex than what you propose but has several significant benefits:
> * We need LDAP proxy for other purposes so there will be a reuse of code
> and framework

What other purposes ?

> * We already have expertise
> * It allows us to keep what we already have done without any conceptual
> changes and continue with the approach we have been developing framework
> for last 4 years

I do not think there is any need to make substantial changes to the
framework with either proposal, and both would cause similar changes
anyway.

> * It can be developed independently and incrementally without affecting
> the core IPA and its release schedule

Same for both approaches.

> * It does not require and knowledge of the internals of IPA framework or
> DS plugins and can be developed by an external contributor

Same level of knowledge is required for both approaches.

> I agree that virtual entries and staging areas are not the right
> approach. I also do not think that penrose at least in its current
> incarnation is the right approach either.
> Leveraging a python based LDAP proxy sounds like a good starting point.

I think it is a bad idea.

> With that I suggest to move this conversation from what to who and how.
> Do we have an RFE logged?

I suggest we do nothing, I think there is a substantial under-estimation
of what it means to introduce an LDAP proxy on top of the framework, or
on the side, or whatever, it is not even clear at what level this proxy
would operate and with what semantics, and it is a substantially larger
project than the plugin I proposed. It would divert substantial
resources, and take a long time to be made useful.

NAK.

Simo.

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