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

[Sumit Bose]

On Fri, Feb 15, 2013 at 05:59:58PM -0500, Simo Sorce wrote:
> 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.

I agree with Simo here, besides other just two important aspects here.
First, since all LDAP request will go through the proxy it needs a good
security audit if a new project is used here, if 389ds or OpenLDAP are
used here this would be different because they already have some history
in this respect. Second, the proxy must support Kerberos/GSSAPI for
authentication and must the able to delegate the credentials to the
following processes.

> 
> > 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.

Although I like the proxy idea in general, I agree. A general purposes
proxy as it was suggested is a major research project and adding and
modifying users, groups, host etc with plain LDAP operations (i.e.
something like the FreeIPA API via LDAP) might be the key feature for
FreeIPA v4 or v5, if we really want it.

bye,
Sumit

> 
> NAK.
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel