[Freeipa-devel] kerberos auth issue

[Rob Crittenden]

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.

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.

Updating rpcclient.py to know the difference between a local and an 
XML-RPC call just feels wrong since rpcclient.py will be visible on 
untrusted client machines. I'm not sure I want to advertise to every IPA 
client that there is a local mechanism (b/c it won't be available).

The function call names in the RPC client and server are the same (all 3 
of them currently) and I wonder if we can use that to our advantage.

A typical rpcclient.py call looks like:

server = xmlrpclib.ServerProxy()
result = server.somefunction(args)

A typical webclient.py looks like:

opts={}
opts['remoteuser'] = req.user
result = funcs.somefunction(args, opts)

Otherwise everything else will be the same. I'm having a hard time 
abstracting this. I suppose we could add yet another layer on this and 
have a client.py that does all the actual work. The API would be:

function(args, opts=None)

If opts is None then we're doing RPC, otherwise local. But this will be 
a very, very long stack.

req.user will hold the principal we're going to proxy as. Not sure how 
we'll do this in turbogears but we can probably fake it for a while 
(until we get it running in mod_python).

So, any ideas? I have the feeling there is some clever python trick we 
can use.

thanks

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/118cc4ad/attachment.bin>