Client identity selection: stored mappings

[ghudson@MIT.EDU]

As mentioned earlier, we want the GSSAPI-krb5 code to look up a client
principal name based on some information about the target service.  In
the first cut, the information available will likely be the service
name and hostname as provided to GSSAPI.  Later on, additional
information might be available from application-provided hints (such
as application name and application account name).  The first cut will
probably require mappings to be maintained out of band, but later
there might be in-band mechanisms for updating it.

I don't have a detailed proposal for mappings yet.  We don't have much
history in accessing user-specific configuration yet.  Some open
questions:

* People have already suggested that the mapping system be pluggable.
  Should there be some kind of aggregation of mapping modules--perhaps
  just a configurable module order?  Or should there be just one
  mapping module, and you can configure what it is?

* It would be possible to just make a pluggable mapping system and not
  create a default module for it.  (No module means no mappings, in
  which case GSSAPI clients would just use the default principal.)
  We've done things like that in the past, but it tends to hinder
  testing and adoption.

* Should there be system mappings in addition to user mappings?  This
  would probably require some kind of wildcard result which is then
  matched against the set of available client credentials.  If there
  are system mappings, does it make sense to use the domain_realm
  section as a fallback?

* We'll be starting with at least two lookup criteria (target hostname
  and target service name).  What kind of wildcarding should be
  supported, and how should the search order work?  KIM provides some
  precedent here.

For the default user mapping module:

* File location: $HOME/.krb5/idmap?  Something else?

* File format: profile?  XML?  Whitespace-separated fields?  Something
  else?

* Update discipline for in-band updates: atomic replacement via
  rename?  That works on Unix but not Windows.  Other options?

(KIM uses an OSX preferences file to hold user mappings, which doesn't
provide much guidance outside of that platform.)