[Freeipa-devel] LDAP over XML

Rob Crittenden rcritten at redhat.com
Thu Jul 19 18:02:30 UTC 2007


Karl MacMillan wrote:
> On Thu, 2007-07-19 at 09:26 -0400, Rob Crittenden wrote:
>> Karl MacMillan wrote:
>>> On Thu, 2007-07-19 at 07:54 -0400, Etienne Goyer wrote:
>>>> Hi guys,
>>>>
>>>> I'm just a lurker interested in FreeIPA.  I do not want to waste your
>>>> time, but I wonder ...
>>>>
>>>> Rob Crittenden wrote:
>>>>> Rob Crittenden wrote:
>>>>>> I've been going back and forth over how much LDAP information to
>>>>>> reveal over RPC. At this point it is simply easier to reveal it all
>>>>>> (as granted by LDAP ACLs of course). We can remove stuff in the future
>>>>>> (like objectclass) but for now I'm going to transmit everything I think.
>>>> Why do "LDAP over XML" in the first place ?  Can't the client just query
>>>> the directory server directly ?  This seem very awkward to me.
>>>>
>>> I have to agree - as soon as we start passing back ldif we should just
>>> go for LDAP queries.
>>>
>> Sigh. Look. We have to pass back data to the client somehow right? And 
>> the data may be binary which, while supported by RPC, without a schema 
>> parser I can't easily identify them (without hardcoding).
>>
>> So I'm passing back a dict of all values returned by a search, the 
>> easiest thing to do. Obviously at some point we could restrict it to 
>> just the fields requested, not send objectclass, whatever. But it is 
>> simply easier to send everything.
>>
>> It is trivial to parse an LDIF into a dict and return that. This way the 
>> fields that need to be encoded are encoded and the rest are plain 
>> strings. On the receiving side you can do easy stuff like user['cn'] or 
>> add a __getattr_ and do user.cn.
>>
> 
> So in that scheme the LDIF parsing is server side?

Right.

>> One advantage that this RPC approach has is writing clients is trivial. 
>> I wrote a basic adduser CLI client in about 3 minutes yesterday. A 
>> shared library does the same thing for us but is language dependant. I'm 
>> not invested in one way or the other but we must decide very soon. Its 
>> hard to develop on shifting sands.
>>
> 
> Definitely on all points.
> 
>> And remember all this is moot if we can't do forwarded kerberos tickets. 
>> At this point I'm completely blocked on it and have moved onto other 
>> things that need to be done. It might be a good exercise for someone 
>> else to stand up freeipa and try to get basic kerberos working like I 
>> did. Then they can stick Apache in the mix and see if they can get 
>> forwarding to work in their environment.
>>
> 
> Right - so it seems everyone agrees that the forwarded tickets and
> xml-rpc layer would be nice, but like you said we need to make forward
> progress. Let's push on the ticket forwarding today and tomorrow (and
> pull in some help from upstream / others). If we haven't resolved it by
> then I vote for going to the library solution plus ldapi.

How does ldapi helps us? Who will it bind as?

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20070719/bf2ffdf5/attachment.bin>


More information about the Freeipa-devel mailing list