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