logo_kerberos.gif

Difference between revisions of "Projects/DBAliases"

From K5Wiki
Jump to: navigation, search
(New page: {{project-early}} Currently the MIT KDC implementation contains support for name canonicalization; however, neither of the shipped back ends has any support for aliases or principal name ...)
 
Line 10: Line 10:
   
 
== Design ==
 
== Design ==
  +
  +
* The DB2 back end will grow a third database, named with a ".alias" extension to the base DB name.
  +
* The new database will map alias principal names to canonical principal names. In order to facilitate automatic generation of the alias database, there will be no flags or extensibility fields in the values. Keys and values will both contain the realm component of the principal, however.
  +
* krb5_db2_db_get_principal will, on failure to find the principal in the main database, consult the alias database and try to canonicalize the principal name. If successful, it will look up the canonical name in the main database.

Revision as of 17:29, 5 March 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


Currently the MIT KDC implementation contains support for name canonicalization; however, neither of the shipped back ends has any support for aliases or principal name transformation on lookup. This project will implement basic alias support for the DB2 and hopefully the LDAP back ends. A major use case for this feature is servers with more than one hostname. Case folding and other transformations of principal names are out of scope.

Functional Requirements

  • It must be possible to create aliases in the DB2 back end such that looking up the alias produces the entry for the canonical name.
  • It must be possible to synchronize aliases for host principals with an outside source of information such as a DNS zone file.
  • For feature parity, it is desirable if aliases can also be created in the LDAP back end.

Design

  • The DB2 back end will grow a third database, named with a ".alias" extension to the base DB name.
  • The new database will map alias principal names to canonical principal names. In order to facilitate automatic generation of the alias database, there will be no flags or extensibility fields in the values. Keys and values will both contain the realm component of the principal, however.
  • krb5_db2_db_get_principal will, on failure to find the principal in the main database, consult the alias database and try to canonicalize the principal name. If successful, it will look up the canonical name in the main database.