logo_kerberos.gif

Difference between revisions of "Projects/DBAliases"

From K5Wiki
Jump to: navigation, search
Line 1: Line 1:
 
{{project-early}}
  
{{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 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.
 +
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 very basic read-only alias support for the DB2 back end. The primary use case for this feature is servers with more than one hostname. Case folding and other transformations of principal names are out of scope. Management and propagation of aliases is out of scope.
   
 
== Functional Requirements ==
  
== Functional Requirements ==
Line 7: Line 7:
 
* 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 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.
  
* 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 ==
  
== Design ==
   
−
* The DB2 back end will grow a third database, named with a ".alias" extension to the base DB name.
 +
* The DB2 back end will attempt to open an existing database named with ".alias" appended to the base DB name. If this database does not exist, it will be assumed that there are no aliases.
−
* 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.
 +
* The alias database will map alias principal names to canonical principal names (with realms, in both cases). In order to facilitate automatic generation of the alias database, there will be no flags or extensibility fields in the values.
 
* 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.
  
* 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.
  +
* There will be no changes to the delete-principal or iterate operations. Aliases do not exist from their point of view.
  +
* If necessary, a short C program will be provided to manipulate the alias database. (Investigate whether this is possible with Perl's DB_File or with Python in a manner compatible with Kerberos.)
  +
* A sample script, or feature of the short C program, will be provided to synchronize an alias database with the CNAME entries from a BIND zone file.

Revision as of 17:31, 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 very basic read-only alias support for the DB2 back end. The primary use case for this feature is servers with more than one hostname. Case folding and other transformations of principal names are out of scope. Management and propagation of aliases is 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.

Design

  • The DB2 back end will attempt to open an existing database named with ".alias" appended to the base DB name. If this database does not exist, it will be assumed that there are no aliases.
  • The alias database will map alias principal names to canonical principal names (with realms, in both cases). In order to facilitate automatic generation of the alias database, there will be no flags or extensibility fields in the values.
  • 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.
  • There will be no changes to the delete-principal or iterate operations. Aliases do not exist from their point of view.
  • If necessary, a short C program will be provided to manipulate the alias database. (Investigate whether this is possible with Perl's DB_File or with Python in a manner compatible with Kerberos.)
  • A sample script, or feature of the short C program, will be provided to synchronize an alias database with the CNAME entries from a BIND zone file.
Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/DBAliases&oldid=1208"