Difference between revisions of "Projects/Local authorization pluggable interface"

Revision as of 13:40, 30 January 2013

Description

This project adds a pluggable interface to affect the behavior of the krb5_kuserok() and krb5_aname_to_localname() functions.

Background

The krb5_aname_to_localname() function attempts to convert a krb5 principal name into a local account name according to policy. The default behavior maps single-component principals within the default realm to their values without realm (e.g. ghudson@ATHENA.MIT.EDU to ghudson, if ATHENA.MIT.EDU is the default realm). Its behavior can be modified through profile configuration as outlined below:

   [realms]
       DEFREALMNAME = {
           auth_to_local_names = {
               princname = localname
           }
           auth_to_local = RULE:[selstring](regexp)s/pattern/replacement/
           auth_to_local = DEFAULT
       }

The krb5_kuserok() function decides whether a principal name is authorized to control a particular local account name. The current implementation looks for a .k5login file in the local account's home directory and searches it for the principal name; if no .k5login file exists, authorization succeeds if krb5_aname_to_localname maps the principal name to the local account name.

Proposal

This project proposes to use a single pluggable interface to control the behavior of both operations. A module may choose to only implement methods to control one or the other function, but the expectation is that a module may wish to use the same internal state to control both operations.

[XXX rough notes follow:]

 * kuserok: princname, localname -> accept/reject or krb5 error; KRB5_PLUGIN_NO_HANDLE implies pass?
   - accumulator behavior: succeed if no modules reject/error and at least one module accepts

 * an2ln: some different design choices
   1. plug into realms -> DEFREALMNAME -> auth_to_local values
      module registers prefix type (like current "RULE" or "DEFAULT")
      method is invoked if module's prefix is selected, perhaps multiple times with different residuals
      config required to take over all an2ln operations is somewhat cumbersome
   2. treat existing support as modules, and add new modules
      accumulator behavior is hard to specify without ordering
   3. module can take over all an2ln operations, but only allow one module to do so

Testing

Documentation

Release notes