logo_kerberos.gif

Difference between revisions of "Projects/Principal entry string mapping"

From K5Wiki
Jump to: navigation, search
(New page: {{project-early}} {{project-target|1.10}} This project will add a string:string mapping to krb5 principal entries in the KDB, along with kadmin support for retrieving and modifying string...)
 
Line 2: Line 2:
 
{{project-target|1.10}}
  
{{project-target|1.10}}
   
−
This project will add a string:string mapping to krb5 principal entries in the KDB, along with kadmin support for retrieving and modifying string mappings. KDC plugins (such as preauth plugins) will be able to examine string mappings.
 +
This project will add a string-to-string mapping to krb5 principal entries in the KDB, along with kadmin support for retrieving and modifying string mappings. KDC plugins (such as preauth plugins) will be able to examine string mappings.
   
 
==Background==
  
==Background==
  +
  +
KDC plugins may need to associate data with principal entries which is not known to the core Kerberos code base. For instance, an OTP preauth plugin needs to know what kind of token is associated with a principal and may also need type-specific information about the token.
  +
  +
Principal entries are extensible through tl-data entries, which have two important limitations for this purpose. First, tl-data keys are centrally assigned integers in a 32-bit number space, so plugin developers would need cooperation from the core code base to get keys assigned. Second, there is no general admin user interface for populating tl-data entries in principals.
  +
  +
==Data Model==
  +
  +
Principal entries will gain a mapping from UTF-8 keys to UTF-8 values, stored via tl-data. The assumption is that principal strings will be fairly short and limited in number, so no great attention is needed to efficiency. There is no particular discipline for assigning string keys; the assumption is that plugins will use prefixes like "otp-" to avoid conflicts. At least initially, there will be no validation on values to ensure that they are well-formed for the consuming plugin, although this could be added in the future by adding validation methods to KDC plugins.
  +
  +
Mappings will be represented by a tl-data value containing an XDR encoding of the sequence of keys and values.
  +
  +
==Interface Design==
  +
  +
===User Interface===
  +
  +
The following kadmin commands will be added:
  +
  +
* set_string, setstr: Set a mapping on a principal.
  +
* get_strings, getstrs: View mappings associated with a principal.
  +
* del_string, delstr: Remove a mapping from a principal.
  +
  +
(TODO: Flesh out arguments.)
  +
  +
===Admin Protocol===
  +
  +
The tl-data representation of string mappings will not be exposed in the admin interface, and strings will not appear in kadm5 principal entries. Instead, new RPCs will be added:
  +
  +
* modify_strings: Change or unset one or more mappings on an entry.
  +
* get_strings: Get the list of mappings on an entry.
  +
  +
(TODO: Flesh out arguments and return values.)
  +
  +
===Propagation and Backup===
  +
  +
The tl-data representation of string mappings will be exposed in the dump file format and incremental propagation protocols.

Revision as of 14:49, 12 September 2011

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.


This project is targeted at release 1.10.


This project will add a string-to-string mapping to krb5 principal entries in the KDB, along with kadmin support for retrieving and modifying string mappings. KDC plugins (such as preauth plugins) will be able to examine string mappings.

Background

KDC plugins may need to associate data with principal entries which is not known to the core Kerberos code base. For instance, an OTP preauth plugin needs to know what kind of token is associated with a principal and may also need type-specific information about the token.

Principal entries are extensible through tl-data entries, which have two important limitations for this purpose. First, tl-data keys are centrally assigned integers in a 32-bit number space, so plugin developers would need cooperation from the core code base to get keys assigned. Second, there is no general admin user interface for populating tl-data entries in principals.

Data Model

Principal entries will gain a mapping from UTF-8 keys to UTF-8 values, stored via tl-data. The assumption is that principal strings will be fairly short and limited in number, so no great attention is needed to efficiency. There is no particular discipline for assigning string keys; the assumption is that plugins will use prefixes like "otp-" to avoid conflicts. At least initially, there will be no validation on values to ensure that they are well-formed for the consuming plugin, although this could be added in the future by adding validation methods to KDC plugins.

Mappings will be represented by a tl-data value containing an XDR encoding of the sequence of keys and values.

Interface Design

User Interface

The following kadmin commands will be added:

  • set_string, setstr: Set a mapping on a principal.
  • get_strings, getstrs: View mappings associated with a principal.
  • del_string, delstr: Remove a mapping from a principal.

(TODO: Flesh out arguments.)

Admin Protocol

The tl-data representation of string mappings will not be exposed in the admin interface, and strings will not appear in kadm5 principal entries. Instead, new RPCs will be added:

  • modify_strings: Change or unset one or more mappings on an entry.
  • get_strings: Get the list of mappings on an entry.

(TODO: Flesh out arguments and return values.)

Propagation and Backup

The tl-data representation of string mappings will be exposed in the dump file format and incremental propagation protocols.

Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/Principal_entry_string_mapping&oldid=3955"