[20515] in Kerberos_V5_Development
Authz on the KDC itself - check_kdcpolicy_tgs can't inspect client?
daemon@ATHENA.MIT.EDU (Felix Friedlander via krbdev)
Mon Dec 16 16:38:02 2024
Message-ID: <cf173125-8514-4735-8028-d23be336737b@anu.edu.au>
Date: Tue, 17 Dec 2024 07:36:32 +1100
Content-Language: en-AU
To: krbdev@mit.edu
MIME-Version: 1.0
From: Felix Friedlander via krbdev <krbdev@mit.edu>
Reply-To: Felix Friedlander <felix.friedlander@anu.edu.au>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
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 krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
