[Freeipa-devel] kerberos auth issue

[Simo Sorce]

On Thu, 2007-08-02 at 16:06 -0400, Karl MacMillan wrote:
> On Thu, 2007-08-02 at 15:35 -0400, Simo Sorce wrote:
> > On Thu, 2007-08-02 at 15:30 -0400, 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?
> > 
> > Even better if we can replace cert with krb on the right side as well,
> > even without forwarding, just reauth as a service with LDAP/SASL/GSSAPI
> > 
> 
> Agreed, but the choice is being driven by ease of development right now
> and it seems the python kerb libraries aren't the best.

it should be almost all handled by the sasl libraries linked to the ldap
libraries. all we need to do is to do the equivalent of a kinit before
we initiate the ldap bind. if the python bindings can't even do this
then they are completely broken and worthless (and yes I am volunteering
to do the job later on, when I finish to fight with the kpasswd
stuff :-).

Simo.