[Freeipa-devel] kerberos auth issue

[Karl MacMillan]

On Thu, 2007-08-02 at 16:02 -0400, Rob Crittenden wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-08-02 at 14:36 -0400, Rob Crittenden wrote:
> >> I ran into a problem with my kerberos authentication in the gui
> >> and just as I was preparing the patch.
> >>
> >> The current code calls for the XML-RPC server to be protected by 
> >> kerberos. If authenticated, the server takes REMOTE_USER and uses that 
> >> as the uid when doing proxying (we could also do a search using it as 
> >> krbPrincipalName) so the request comes in via something like 
> >> ipa-finduser which makes the actual HTTP request using the XML-RPC 
> >> client (rpcclient.py)
> >>
> >> It is in there, during the XML-RPC request, that the GSSAPI magic happens.
> >>
> >> Now this same code in rpcclient.py was orignally going to be used by the 
> >> GUI as well (write once, use for both) but the GUI is making the request 
> >> through turbogears/Apache so we won't have the kerberos ticket because 
> >> forwarding doesn't seem to work. One could argue that we'd do the 
> >> kerberos auth in the web server that the GUI attaches to, but then how 
> >> do we pass in the principal name to the XML-RPC server? An unprotected 
> >> URI? Seems risky and we'd still need to get Apache to set REMOTE_USER.
> >>
> > 
> > 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?
> 
> It does but it also means the two clients aren't playing on the same 
> field.

Sure - but that is a good thing. The interactivity of the web browser
and the likelihood of viewing much more data mean that removing the
xmlrpc layer could improve performance substantially. I'm not that
worried about performance with the commandline tools because of how they
are likely to be used.

>  I don't think there is another easy way around it without 
> introducing some ugly mechanism (uglier than a web server talking to a 
> web server).
> 

Not certain what you mean.

> I'll have to consider the impact on the client libraries.
> 

Sure - it will require coding things somewhat differently.

Karl