Projects/DBAliases - Revision history

Ghudson: /* Design */

2009-03-13T19:47:03Z

‎Design

Ghudson: /* Functional Requirements */

2009-03-13T19:40:00Z

‎Functional Requirements

Ghudson at 22:31, 5 March 2009

2009-03-05T22:31:44Z

Ghudson at 21:29, 5 March 2009

2009-03-05T21:29:02Z

Ghudson: 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 ...

2009-03-05T19:39:10Z

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 ...

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 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 ==

@@ Line 10: / Line 10: @@
 == Design ==
 * 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.

@@ Line 1: / Line 1: @@
 {{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 ==
@@ 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 synchronize aliases for host principals with an outside source of information such as a DNS zone file.
 == 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.

← Older revision		Revision as of 21:29, 5 March 2009
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.