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

[Dmitri Pal]

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.

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
* 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
* It can be developed independently and incrementally without affecting
the core IPA and its release schedule
* It does not require and knowledge of the internals of IPA framework or
DS plugins and can be developed by an external contributor

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.

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

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/