[Freeipa-devel] kerberos auth issue

[Simo Sorce]

On Fri, 2007-08-03 at 12:09 -0400, 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             |
> ------------------------------
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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?

This is how I would do it as well.
The xml-rpc stuff should just be a transport layer to reach the server
api.

All functions to access data should be implemented there, UI specific
handling will be instead in the CLI or the GUI as needed.

Simo.