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

Hi all,

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.

AFAIK, the standard way to do this would be to make the authorisation 
decision on the host being accessed, using some central source of truth 
- LDAP being an obvious choice, given its ready integration with kerberos.

However, aside from the obvious increased complexity, this introduces a 
few downsides:
* all hosts need to be in communication with a central server (something 
krb otherwise does /not/ require);
* configuration of which user(s) / group(s) can access a given host is 
done per-host, on the host (though you can use configuration management 
software or similar to streamline this);
* this doesn't play particularly nice with techniques which map several 
principals to a single local user (for e.g. when a server only needs to 
be accessed for administrative purposes, and local user accounts for the 
administrators are unnecessary).

A KDC already has a database of users and hosts/services, the ability to 
associate metadata with them (string attributes, among other options), 
and has control over whether or not a service ticket is issued for a 
given pair of principals. Why not make some authorisation decisions there?

I was hoping to prototype this in a kdcpolicy plugin; however, 
check_kdcpolicy_tgs doesn't receive the "client" parameter that 
check_kdcpolicy_as does, so a plugin (currently) can't inspect the 
requesting principal at ticket-granting time. Is there a reason this 
information isn't exposed? As far as I can tell, it /is/ available at 
the relevant location in process_tgs_req.

(If it is safe to add, I'm happy to submit a patch to allow a new major 
version of kdcpolicy - which I think would be needed to change 
krb5_kdcpolicy_check_tgs_fn.)

Any other thoughts on the concept? I'm not trying to say that this is 
the best way to do authorisation, just that it seems possible, and might 
be useful in some contexts.

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