[Freeipa-devel] another snag with kerberos

[Karl MacMillan]

On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-07-19 at 12:36 +1000, Andrew Bartlett wrote:
> >   
> >> On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote:
> >>     
> >>> Andrew Bartlett wrote:
> >>>       
> >>>> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote:
> >>>>         
> >>>>> In any case we can't do anything until we find a way to do kerberos SSO 
> >>>>> with ticket forwarding using some sort of HTTP engine. 
> >>>>>           
> >>>> Ticket forwarding is on the esoteric end of the kerberos spectrum, and I
> >>>> wonder if for IPAv1 we should instead have the XMLRPC server simply be
> >>>> trusted?  (Bind as EXTERNAL, then do LDAP proxy authorization). 
> >>>>         
> >>> I'm all in favor of a solution that will work. Do you have any details 
> >>> on how one might do this and whether it is supported by mod_auth_kerb?
> >>>
> >>> The way the communication goes is this:
> >>>
> >>> Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP
> >>>       
> >> Why do we have the RPC client -> RPC server layer here?  
> >>
> >>     
> >>> So we need some way of grabbing the credentials and passing them all the 
> >>> way to LDAP so we can bind as the user who is logging into Apache.
> >>>
> >>> Knowing next-to-nothing about SASL I'm going to need some hand-holding 
> >>> to get this configured and working.
> >>>       
> >> I suppose I expected (having clearly not followed this enough) that the
> >> layers were:
> >>
> >> User-> web browsser -> Apache/mod_auth_kerb -> LDAP
> >>
> >> User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP
> >>
> >> In these cases, you could authenticate the Apache/mod_auth_kerb by
> >> simply asserting your identity to LDAP over ldapi://
> >>
> >>     
> >
> > Ahh - I see. So on local communications with the LDAP server you can
> > just assert your identity with no authentication.
> >   
> Kinda, except that we cannot rely upon ldapi being available i.e. we 
> can't use it. I added it to FDS earlier this year but it won't have 
> filtered through in time for us I'm afraid.

In previous discussions I thought we had decided that it would be
available if we were willing to assume the testing burden.

>  However, it is not required 
> that ldapi is used in order to take advantage of LDAP proxy 
> authentication - but we are left with a credential problem we didn't 
> have before. System level authentication using ldapi is definitely neater.

And seems like the correct solution to me.

> > That solves our problem assuming that we can somehow handle the
> > authentication through the web gui to the xmlrpc layer. We could:
> >
> > 1) remove the xmlrpc layer (either entirely or just for the web gui)
> >   
> > 2) invent some way to pass who the user is and handle 'local'
> > communication between the gui and xmlrpc layer.
> >
> > We've debated several times whether the xmlrpc layer is truly useful - I
> > like it mainly because it gives a language neutral interface. However,
> > since it is causing a signification amount of complexity (not just this
> > - there is also the API design issues) I suggest we drop it for v1. We
> > can simply use a common python library for the web and commandline
> > interfaces. That should reduce our development time as well.
> >
> > Thoughts?
> >   
> As devil's advocate I feel compelled to point out that an approach that 
> places the system logic into client libraries (rather than on the 
> server) runs the risk of much more resistance to change in the future, 
> since now that change has a greater and more far reaching impact: 
> clients get built, sold, and generally hang around being a nuisance.
> 
> Language neutral is also a big win.
> 
> At this point though, we need something that works now.
> 

Agreed on all 3 points - which is why I suggested it :) I think this is
a short-term architectural decision not a long term one.

Karl