[Freeipa-devel] kerberos auth issue

[Rob Crittenden]

Karl MacMillan wrote:
> On Fri, 2007-08-03 at 11:42 -0400, Rob Crittenden wrote:
>> Karl MacMillan wrote:
>>> I thought that the backend of the xml-rpc library was going to be a
>>> python library that the web gui would use directly. The architecture
>>> would be:
>>>
>>> xmlrpc-client -----> xmlrpc-server -------> DS
>>>                krb                   cert
>>> browser -----------> web server ----------> DS
>>>
>>> That eliminates all of the problems, right?
>>>
>>> Karl
>>>
>> Long, sorry in advance.
>>
>> Part of the problem I'm having is that rpcclient.py does a bit of data 
>> massaging. We can move some of this to the server side, it probably 
>> belonds there anyway (such as including extra attributes when adding a 
>> user). This move will be done later.
>>
> 
> Agreed - if our local client library does too much then the usability of
> the xmlrpc api will go down dramatically.
> 
>> But with other stuff some data conversion happens and that has to be in 
>> the client.
>>
>> As a test I copied rpcclient.py to webclient.py and updated my basic TG 
>> gui to use webclient.py instead. All I did was replace the server. calls 
>> with funcs. calls (effectively skipping the XML-RPC call). The one call 
>> I tested worked with no changes to the GUI code except changing the API 
>> names.
>>
>> So. I think that if we expand on this idea we can still have a 
>> more-or-less unified client API, but one goes through XML-RPC and one 
>> doesn't. The trick will be telling which is which. This is where I'm 
>> getting hung up.
>>
>> So simply copying rpcclient.py to webclient.py is obviously wrong, code 
>> duplication up the wazoo.
>>
> 
> Now - I may just have this all wrong because I'm not familiar enough
> with the details, but what I had imagined was a bit different. I assumed
> that we would have a common layer underneath the xmlrpc server and web
> server:
> 
> ----------      --------------
> | xmlrpc |      | web server |
> ----------      --------------
> ------------------------------
> |    python serverlib.py     |
> ------------------------------
>               ||
>               ||
>               \/
> ------------------------------
> |             DS             |
> ------------------------------

That is the way it is architected now. The xmlrpc part does some 
translation of the unmarshalled data into a more application-specific 
form. That is where I'm having difficulties.

> The role of serverlib.py is to abstract away the ldap detail so that we
> get calls like:
> 
> adduser(realm, userObject)
> uerObject = finduser(realm, userName)
> 
> It would handle authenticating to the DS locally, ldap calls, and
> provide a unified data model. That means userObject would be a python
> object that has all of the 'exported' attributes of a user (including
> custom attributes set by a local admin).

Yup, that is the goal.

> Both the xmlrpc and web gui would be written to this api and would
> really only be concerned with the details unique to each. For the xmlrpc
> server that means, really, just marshalling / unmarshalling data and
> making calls to serverlib.py. The web server would just be the web
> presentation layer.

That's the thing. Currently the XML-RPC client does more than unmarshall 
the data. It converts it into another python class. Remember that 
XML-RPC only defines like 6 data types. If we have each client convert 
that raw data into an object we'll have lots of code duplication. I'd 
like to do that work for the client.

> Now, what seems to be concerning you is that the data model in
> serverlib.py will be very similar to the data model in rpcclient.py (and
> there will be some overlap in xmlrpc), correct? That seems easy to
> handle if you make the data objects (like userObject above) simple
> collections of data and factor out marshalling / unmarshalling to xmlrpc
> and ldap. So, you get something like user.py which is shared by
> serverlib.py and rpcclient.py (as in shipped in both) and used by the
> xmlrpc server.

Actually, the data model on the server side is an LDAP entry (the Entry 
class in ipaldap.py). The data model on the client side is the User 
object (not yet shipped).

> You would also have userldap.py (unique to serverlib.py) and
> userxmlprc.py. Those would contain functions for doing data conversion,
> etc., etc.
> 
> Does that make any sense or help in any way?

It confirms that we're on the same page which is a good thing (TM).

The main problem I'm having is not disclosing to the world that there is 
a special type of client that can connect directly. What I want to avoid 
is the situation where someone with no kerberos ticket is able to call 
the local functions and access the DS directly.

 From TurboGears to serverlib.py we have no TGT so we have to trust that 
TurboGears is setting the kerberos principal name correctly. If someone 
is able to change that they can proxy as anyone they want.

I think Kevin has a decent model if that I can get that implemented.

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/20070803/72bd9c9e/attachment.bin>