Re: Authz on the KDC itself - check_kdcpolicy_tgs can't inspect client?

>I've been thinking about how to adapt (MIT) Kerberos to do simple 
>authorisation - think something like: user principals are authorised to 
>access particular "groups" of host/service principals.

To add to some of Greg's comments:

- One additional issue that might not be obvious is that if you want to
  disable access to a service, if you based this on ticket issuance
  then you are kind of stuck until any existing Kerberos tickets expire
  before authorization is truely removed.

- If you place group membership inside of a Kerberos ticket and don't
  simply require ticket possession, then when you add access for someone
  they won't have access to that resource until they get a new Kerberos
  ticket.  That's easier to resolve because you have just have them
  re-kinit, but still is annoying.

That being said ... I understand why people do this, and the pieces actually
already sort-of exist in the KDC.

First, there is already existing code that will reject service ticket
issuance based on authentication indicators, as detailed here:

  https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/auth_indicator.html

The trick THEN becomes: how do you get the desired authentication indicators
into the ticket?

Right now the existing code is designed to do it for certain
preauthentication types.  If you use PKINIT, there is a plugin interface
(certauth) that lets you put any arbitrary authentication indicator
in the ticket.  Greg mentioned the PAC code; that can also add auth
indicators, but that requires support from the KDB module and right now
existing KDBs don't have that ability.  You could write a "stackable"
KDB module which intercepts an existing module; MIT added support for
that in this pull request:

	https://github.com/krb5/krb5/pull/1396

And you could add your own issue_pac plugin function that directly
returned whatever authentication indicators you want which could be used
by the existing TGS issuance code.  Note that code hasn't yet appeared
in a MIT Kerberos release yet and the KDB interface isn't considered
stable, but it's probably easier to manage that than core changes to the
MIT KDC (I speak from hard-won experience there).  There is also the
authdata plugin interface which is also considered non-stable, but that
looks like it might be complicated to use in practice.

If application servers use krb5_kuserok() or gss_userok() to make
authorization decisions, a localauth plugin might be the way to go
there; unfortunately all you get to make the decision is the principal
name and the "local" account name, nothing else from the Kerberos ticket.
We have our own localauth plugin at our site, and it works very well.

--Ken
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev