[Freeipa-devel] another snag with kerberos

[Rob Crittenden]

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

The purpose of RPC is to make it very easy for a customer to implement 
their own GUI. It also lets us do all the hard work once and just glue 
on a CLI and GUI on top of it.

> In these cases, you could authenticate the Apache/mod_auth_kerb by
> simply asserting your identity to LDAP over ldapi://

We're supposed to be hiding the fact that LDAP exists. In any case, I'm 
not sure how I can assert identity if I can't forward the ticket using 
the browser.

>>> This would also allow non-kerberos authentication, and remove a pile of
>>> complexities that could bite us very badly.  For example:  Even if we
>>> get the forwarded ticket, will it have an address restriction on it?
>>> (The mechanism clients have used - dns lookup of target principal - for
>>> choosing those addresses have sometimes given very poor results). 
>>>
>>> We could then revisit this later, perhaps combined with KDC
>>> modifications to be far less dependent on client behaviour (Heimdal has
>>> some very neat solutions, driven by the practical integration needs of
>>> the University of Stockholm). 
>> We're committed to MIT at this point.
> 
> Yeah, while I think that's a poor commitment, it's not one I expect to
> influence.

I have no dog in that hunt but I agree.

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/20070718/c3661745/attachment.bin>