Projects/Responder - Revision history

Ghudson at 23:32, 17 September 2012

2012-09-17T23:32:28Z

Ghudson: /* Proposal */

2012-09-05T15:30:43Z

‎Proposal

Npmccallum at 18:17, 4 September 2012

2012-09-04T18:17:51Z

Npmccallum: Projects/Response set moved to Projects/Responder

2012-09-04T14:27:21Z

Projects/Response set moved to Projects/Responder

Ghudson: Projects/ResponseSet moved to Projects/Response set: Consistency with other wiki page names

2012-07-12T18:46:23Z

Projects/ResponseSet moved to Projects/Response set: Consistency with other wiki page names

Ghudson at 18:45, 12 July 2012

2012-07-12T18:45:29Z

Ghudson at 15:43, 11 July 2012

2012-07-11T15:43:46Z

Npmccallum at 15:23, 11 July 2012

2012-07-11T15:23:40Z

Npmccallum at 15:22, 11 July 2012

2012-07-11T15:22:24Z

Npmccallum at 15:18, 11 July 2012

2012-07-11T15:18:15Z

← Older revision		Revision as of 23:32, 17 September 2012
Line 1:		Line 1:
−	{{project-~~review~~\|~~2012-07-20~~}}	+	{{project-rel\|1.11}}
−	{{project-target\|1.11}}

	== Description ==		== Description ==

@@ Line 16: / Line 16: @@
 == Proposal ==
-The Responder allows client preauth plugins to define questions (and optional structured/encoded challenge data) which will be collected and asked once for the entire set from a libkrb5 callback. This callback can view which questions have been asked, optionally inspect the challenge data and then provide structured/encoded answers back to libkrb5. The end result is that inside the responder callback, the application has full knowledge of every question asked, including complext questions and can provide back a single set of potentially complex answers.
+The responder allows client preauth plugins to define questions (and optional structured/encoded challenge data) which will be collected and asked once for the entire set from a libkrb5 callback. This callback can view which questions have been asked, optionally inspect the challenge data and then provide structured/encoded answers back to libkrb5. The end result is that inside the responder callback, the application has full knowledge of every question asked, including complex questions, and can provide back a single set of potentially complex answers.
 libkrb5 will add the following new functions and types to gic_opts:

@@ Line 4: / Line 4: @@
 == Description ==
-The response set mechanism is an alternative to the prompting interface for libkrb5 client preauth plugins.
+The responder mechanism is an alternative to the prompting interface for libkrb5 client preauth plugins.
 == Problem ==
@@ Line 12: / Line 12: @@
 Further, the prompter interface requires linear interaction.  If multiple questions are required, they have to be asked in serial.  However, graphical interfaces present to option to answer multiple questions simultaneously.
-The response set mechanism presents the consumer of libkrb5 with a full list of questions needing answers.  The responder callback can consider the list and answer whichever questions it chooses to.  Each named question is a binary contract between the preauth mechanism and the responder callback, allowing complex questions to be handled.
+The responder mechanism presents the consumer of libkrb5 with a full list of questions needing answers.  The responder callback can consider the list and answer whichever questions it chooses to.  Each named question is a string contract between the preauth mechanism and the responder callback, allowing complex questions to be handled.
 == Proposal ==
  <nowiki>
 krb5_error_code KRB5_CALLCONV
@@ Line 31: / Line 41: @@
                                       krb5_get_init_creds_opt *opt,
                                       krb5_responder_fn responder, void *data);</nowiki>
 The responder callback will be called after libkrb5 receives padata, but before the process() function of the clpreauth interface is called.  The responder function will process some or all of the values contained in the response set.
-In order to populate the response set, a new (optional) function will be added to the clpreauth interface:
+In order to populate the set of questions, a new (optional) function will be added to the clpreauth interface:
  <nowiki>
 typedef krb5_error_code
-(*krb5_clpreauth_fill_rset_fn)(krb5_context context,
+(*krb5_clpreauth_prep_questions_fn)(krb5_context context,
-                               krb5_clpreauth_moddata moddata,
+                                    krb5_clpreauth_moddata moddata,
-                               krb5_clpreauth_modreq modreq,
+                                    krb5_clpreauth_modreq modreq,
-                               krb5_get_init_creds_opt *opt,
+                                    krb5_get_init_creds_opt *opt,
-                               krb5_clpreauth_callbacks cb,
+                                    krb5_clpreauth_callbacks cb,
-                               krb5_clpreauth_rock rock,
+                                    krb5_clpreauth_rock rock,
-                               krb5_kdc_req *request,
+                                    krb5_kdc_req *request,
-                               krb5_data *encoded_request_body,
+                                    krb5_data *encoded_request_body,
-                               krb5_data *encoded_previous_request,
+                                    krb5_data *encoded_previous_request,
-                               krb5_pa_data *pa_data);</nowiki>
+                                    krb5_pa_data *pa_data);</nowiki>
 This function will be called after receiving padata, but before the process() function is called.  Its responsibility is to identify any decisions that need to be made and to expose these decisions via the krb5_response_set data structure.
@@ Line 54: / Line 62: @@
 == Expected Behavior ==
 == Testing ==
-In lib/krb5/krb, a new program t_response_set will exercise the internal response set manipulation functions.
+In lib/krb5/krb, a new program t_response_items will exercise the internal k5_response_items manipulation functions.
 == Documentation ==

@@ Line 1: / Line 1: @@
-{{project-early}}
+{{project-review|2012-07-20}}
 {{project-target|1.11}}
@@ Line 62: / Line 62: @@
 == Documentation ==
 == Release notes ==

@@ Line 1: / Line 1: @@
 {{project-early}}
 == Description ==
 The response set mechanism is an alternative to the prompting interface for libkrb5 client preauth plugins.
 == Problem ==
 == Proposal ==
 libkrb5 will add a new callback to gic_opts:
  <nowiki>
@@ Line 28: / Line 32: @@
                                       krb5_responder_fn responder, void *data);</nowiki>
-This callback will be called after libkrb5 receives padata, but before the process() function of the clpreauth interface is called. The main purpose of the responder function is to process any values contained in the interfaces contained in the krb5_response_set. This data type is essentially a name to value mapping. The name is the unique name of some interface a clpreauth plugin wishes to expose to the consumer of libkrb5 and the (void*) value is a handle for the interface. The interface should be detailed in a public header and used both inside the clpreauth plugin and by the responder.
+The response set is a name to value mapping, where the name is the unique name of some interface a clpreauth plugin wishes to expose to the consumer of libkrb5, and the (void *) value is a binary value to be altered by the consumer.  The structure of the binary value should be detailed in a public header and used both inside the clpreauth plugin and by the responder.
 In order to populate the response set, a new (optional) function will be added to the clpreauth interface:
@@ Line 44: / Line 48: @@
                                krb5_pa_data *pa_data);</nowiki>
-This function will be called after receiving padata, but before the process() function is called. Its responsibility is to identify any decisions that need to be made and to expose these decisions via the krb5_response_set data structure.
+This function will be called after receiving padata, but before the process() function is called.  Its responsibility is to identify any decisions that need to be made and to expose these decisions via the krb5_response_set data structure.
 == Expected Behavior ==

← Older revision	Revision as of 14:27, 4 September 2012
(No difference)

← Older revision	Revision as of 18:46, 12 July 2012
(No difference)

@@ Line 5: / Line 5: @@
 == Problem ==
-The existing prompting interface permits client preauth plugins to ask questions of the user in order to resolve conflicts or ascertain data in order to properly process padata. Most commonly this is something akin to asking the user for a password. However, as time has progressed, user interfaces have moved from text based to graphical and the complexity of questions has increased markedly. This results in a situation where the prompter interface isn't adequate to resolve these complex question with subtle user interfaces. Specifically, client preauth plugins need a way to expose a well known API to the consumers of libkrb5 without libkrb5 knowing the details of this API.
+The existing prompting interface permits client preauth plugins to ask questions of the user in order to resolve conflicts or ascertain data in order to properly process padata. Most commonly this is something akin to asking the user for a password. However, as time has progressed, user interfaces have moved from text based to graphical and the complexity of questions has increased drastically. This results in a situation where the prompter interface is not the most efficient way to answer complex questions.
 == Proposal ==

← Older revision		Revision as of 15:18, 11 July 2012
Line 1:		Line 1:
	{{project-early}}		{{project-early}}
		+
		+	== Description ==
		+	The response set mechanism is an alternative to the prompting interface for libkrb5 client preauth plugins.
		+
		+	== Problem ==
		+	The existing prompting interface permits client preauth plugins to ask questions of the user in order to resolve conflicts or ascertain data in order to properly process padata. Most commonly this is something akin to asking the user for a password. However, as time has progressed, user interfaces have moved from text based to graphical and the complexity of questions has increased markedly. This results in a situation where the prompter interface isn't adequate to resolve these complex question with subtle user interfaces. Specifically, client preauth plugins need a way to expose a well known API to the consumers of libkrb5 without libkrb5 knowing the details of this API.
		+
		+	== Proposal ==
		+	libkrb5 will add a new callback to gic_opts:
		+	<nowiki>
		+	typedef void *
		+	(krb5_response_set_get_item_fn)(krb5_context context, krb5_response_set rset,
		+	const char *name);
		+
		+	typedef krb5_error_code
		+	(krb5_responder_fn)(krb5_context context, void data, krb5_response_set *rset,
		+	krb5_response_set_get_item_fn get_item);
		+
		+
		+	krb5_error_code KRB5_CALLCONV
		+	krb5_get_init_creds_opt_set_responder(krb5_context context,
		+	krb5_get_init_creds_opt *opt,
		+	krb5_responder_fn responder, void *data);</nowiki>
		+
		+	This callback will be called after libkrb5 receives padata, but before the process() function of the clpreauth interface is called. The main purpose of the responder function is to process any values contained in the interfaces contained in the krb5_response_set. This data type is essentially a name to value mapping. The name is the unique name of some interface a clpreauth plugin wishes to expose to the consumer of libkrb5 and the (void*) value is a handle for the interface. The interface should be detailed in a public header and used both inside the clpreauth plugin and by the responder.
		+
		+	In order to populate the response set, a new (optional) function will be added to the clpreauth interface:
		+	<nowiki>
		+	typedef krb5_error_code
		+	(*krb5_clpreauth_fill_rset_fn)(krb5_context context,
		+	krb5_clpreauth_moddata moddata,
		+	krb5_clpreauth_modreq modreq,
		+	krb5_get_init_creds_opt *opt,
		+	krb5_clpreauth_callbacks cb,
		+	krb5_clpreauth_rock rock,
		+	krb5_kdc_req *request,
		+	krb5_data *encoded_request_body,
		+	krb5_data *encoded_previous_request,
		+	krb5_pa_data *pa_data);</nowiki>
		+
		+	This function will be called after receiving padata, but before the process() function is called. Its responsibility is to identify any decisions that need to be made and to expose these decisions via the krb5_response_set data structure.
		+
		+	== Expected Behavior ==
		+	All memory stored within the interface exposed via krb5_response_set should be allocated and freed by the clpreauth plugin. The plugin should anticipate that the responder may not process one or more of its exposed interfaces. The plugin may fall back to the prompter interface in that case.