Kerberos for authentication, php for authorization

Simon Wilkinson simon at sxw.org.uk
Fri Jun 8 13:14:38 EDT 2007


On 8 Jun 2007, at 17:34, Michael B Allen wrote:

> On Fri, 8 Jun 2007 09:00:09 +0100
> Simon Wilkinson <simon at sxw.org.uk> wrote:
>
>> Ultimately, this means you may need to have a keytab containing
>> multiple different prinicpals for your service, and have
>> mod_auth_kerb accept any one of these principals. Unfortunately, the
>> code isn't there to do that in current mod_auth_kerb's.
>
> This seems odd to me. The krb5 lib should automatically seek out the
> right key by searching for the desired principal, enctype and kvno.

No, that's not how it works if you specify a principal when you call  
gss_accept_sec_context. When a principal is specified the library  
will only accept incoming connections which are directed at that  
principal.

mod_auth_kerb specifies HTTP/<gethostname()> as its acceptor  
principal, unless you override that with a mod_auth_kerb  
configuration directive, and even then you can only change it to use  
a different, single, principal. Historically, that's the best you  
could do with MIT Kerberos, unless you open the keytab, parse it to  
extract principal names, and call gss_accept_sec_context with each of  
them until it works.

Recent MIT libraries (for some value of recent - I'm not sure when  
the code went in) allow you to pass GSS_C_NO_CREDENTIAL in to the  
gss_accept_sec_context routine, so that it will accept any principal  
in the keytab. I suspect that this is the behaviour you are relying  
on - but mod_auth_kerb doesn't invoke the GSSAPI library in this way,  
and so doesn't have that feature.

Aside: If you're using a single, general purpose, keytab you almost  
certainly _don't_ want the GSS_C_NO_CREDENTIAL behaviour - you want  
to be sure that your ssh service will only accept 'host/' principals,  
for example.

Cheers,

Simon.




More information about the Kerberos mailing list