Difference between revisions of "Projects/kadmin access interface"

Revision as of 11:32, 9 June 2017

This project implements a pluggable interface to allow more flexible access control for kadmin operations.

Background

The kadmin facility allows administration of a Kerberos database in two ways. In the normal scenario, the kadmin client calls into libkadm5clnt, which authenticates to kadmind and transmits requests via an XDR-based protocol. kadmind executes the requests by calling into libkadm5srv, which in turns calls into libkdb5:

   kadmin --> libkadm5clnt ==> kadmind --> libkadm5srv --> libkdb5

Alternatively, an administrator can run kadmin.local on a KDC host (or with permissions to directly access the database, if LDAP or a similar KDB module is in use). kadmin.local can "authenticate" as any user, and directly calls into libkadm5srv to fulfill requests:

   kadmin.local --> libkadm5srv --> libkdb5

The current built-in access control mechanism is implemented at the kadmind layer, so it does not affect kadmin.local. It reads an ACL file which contains access rules, and checks the authenticated user and requested operation against the rules. The ACL file can also apply restrictions to add-principal and modify-principal operations, which may result in changes to the added or modified principal.

A pluggable interface for access control can solve two use cases:

1. Administrators can implement programmatic access control if the kadm5.acl format is not flexible enough. For instances, a module could allow users to create host principals for hosts in particular subdomains, which is currently not possible with kadm5.acl as we only allow wildcarding of whole principal components.

2. Projects which implement their own KDB module (particularly Samba and IPA) can use the database to control access.

Design

Architecture

One simple design option is to make kadmind tell the KDB module the authenticated client principal. The KDB module could then check access for subsequent operations such as put_principal and change_pwd. kadmin.local would not supply a client principal, so the KDB module would not check access control. This option does not satisfy the first use case and would require the administrator to install a permissive kadm5.acl file, but it would be easy to implement.

The option most in keeping with our past designs is to create a pluggable interface for kadmin access control and convert the existing kadm5.acl code into a module for the interface. Multiple modules can be combined using the usual accumulator semantics for access control modules (a module can return yes, no, or pass; at least one module must say yes and zero modules must say no for an operation to succeed). If a shared object which implements a kadmin access control module also implements a KDB module, it can retrieve the KDB handle from the krb5_context operation to perform database operations.

Module interface