Projects/Credential Store extensions - Revision history

Ghudson at 14:00, 21 July 2012

2012-07-21T14:00:37Z

Ghudson at 17:46, 20 July 2012

2012-07-20T17:46:31Z

Ghudson: /* New APIs */

2012-07-20T17:18:25Z

‎New APIs

Ghudson at 14:47, 11 July 2012

2012-07-11T14:47:28Z

Ghudson at 14:37, 11 July 2012

2012-07-11T14:37:56Z

Simo: /* C bindings */

2012-07-10T19:19:08Z

‎C bindings

Simo: /* C bindings */

2012-05-05T15:24:07Z

‎C bindings

Ghudson: /* gss_strore_cred_into() */

2012-05-04T20:19:25Z

‎gss_strore_cred_into()

Ghudson at 20:19, 4 May 2012

2012-05-04T20:19:15Z

Ghudson: /* New APIs */

2012-05-04T20:12:43Z

‎New APIs

← Older revision		Revision as of 14:00, 21 July 2012
Line 1:		Line 1:
−	{{project-~~review~~\|~~2012-07-20~~}}	+	{{project-rel\|1.11}}
−	{{project-target\|1.11}}

	This project is about adding a set of extensions to GSSAPI to specify credential locations in a mechanism-agnostic way.		This project is about adding a set of extensions to GSSAPI to specify credential locations in a mechanism-agnostic way.

@@ Line 51: / Line 51: @@
 This is analogous to gss_cred_store() except that a specific credential store can be specified (in the krb5 case, generally a ccache file).
 Example:
 URN = 'ccache'
 Value = 'FILE:/tmp/somecc'
 A counter and an array of elements.
@@ Line 65: / Line 65: @@
  /* Extension for credential stores */
-     const char *urn;
+     const char *key;
      const char *value;
- typedef struct gss_cred_store_element gss_cred_store_element_t;
+ typedef struct gss_key_value_element gss_key_value_element_desc;
      OM_uint32 count;
      gss_cred_store_element_t *elements;
- typedef const struct gss_cred_store_struct *gss_const_cred_store_t;
+ typedef struct gss_key_value_set_struct gss_key_value_set_desc;
  #define GSS_C_NO_CRED_STORE ((gss_const_cred_store_t) 0)
@@ Line 85: / Line 85: @@
              gss_OID_set desired_mechs,
              gss_cred_usage_t cred_usage,
-             gss_const_cred_store_t cred_store,
+             gss_const_key_value_set_t cred_store,
              gss_cred_id_t *output_cred_handle,
              gss_OID_set *actual_mechs,
@@ Line 98: / Line 98: @@
              OM_uint32 initiator_time_req,
              OM_uint32 acceptor_time_req,
-             gss_const_cred_store_t cred_store,
+             gss_const_key_value_set_t cred_store,
              gss_cred_id_t *output_cred_handle,
              gss_OID_set *actual_mechs,
@@ Line 111: / Line 111: @@
                OM_uint32         overwrite_cred,
                OM_uint32         default_cred,
-               gss_const_cred_store_t cred_store,
+               gss_const_key_value_set_t cred_store,
                gss_OID_set       *elements_stored,
                gss_cred_usage_t  *cred_usage_stored);

← Older revision		Revision as of 17:18, 20 July 2012
Line 32:		Line 32:

	Structures:		Structures:
−	* gss_cred_store_element_struct
		+	* gss_key_value_element_struct
−	* gss_cred_store_struct
		+	* gss_key_value_set_struct

	If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied.		If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied.

← Older revision		Revision as of 14:47, 11 July 2012
Line 114:		Line 114:
	gss_OID_set *elements_stored,		gss_OID_set *elements_stored,
	gss_cred_usage_t *cred_usage_stored);		gss_cred_usage_t *cred_usage_stored);
		+
		+	== Testing ==
		+
		+	Under tests/gssapi, a test program named t_credstore.c will be added to exercise the new APIs. It will be invoked from t_gssapi.py.
		+
		+	== Release notes ==
		+
		+	Developer experience:
		+
		+	* Add GSSAPI extensions to allow callers to specify credential store locations when acquiring or storing credentials

@@ Line 1: / Line 1: @@
-{{project-early}}
+{{project-review|2012-07-20}}
-This project is about adding a set of extensions to GSSAPI to more easily handle credentials in a mechanism agnostic way.
+This project is about adding a set of extensions to GSSAPI to specify credential locations in a mechanism-agnostic way.
 == Background ==
-During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy.  Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same process environment as the proxied application, and may run multiple concurrent tasks on behalf of different applications with different trust/credentials.
+During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy.  Using the normal defaults of GSSAPI, this not possible, because the proxy application does not run in the same process environment as the proxied application, and may run multiple concurrent tasks on behalf of different applications with different trust/credentials.
 A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism-specific, as the proxy tries to be mechanism-agnostic as much as possible.
@@ Line 21: / Line 21: @@
 == Architecture ==
-The exposed public functions are paired with analogous functions in the mechglue SPI to give mechanisms access to the Credentials Store.
+The exposed public functions are paired with analogous functions in the mechglue SPI to give mechanisms access to the Credentials Store.  gss_add_cred_from is not included in the SPI since the mechglue does not invoke it.  Implementations of gss_acquire_cred_from are provided for krb5 and SPNEGO, and an implementation of gss_store_cred_into is provided for krb5.
 == New APIs ==
 Functions:
 Structures:
@@ Line 39: / Line 39: @@
 === gss_acquire_cred_from() ===
-Acquires new credentials using the provided store.  The store can specify both the actual credentials and/or the credential cache.
+Acquires new credentials using the provided store.  The store can specify both the actual credentials and/or the credential location.
 In the krb5 mechanism case it could specify a keytab and a ccache location.
@@ Line 80: / Line 80: @@
  OM_uint32 gss_acquire_cred_from(
              OM_uint32 *minor_status,
-             const gss_name_t desired_name,
+             gss_name_t desired_name,
              OM_uint32 time_req,
              gss_OID_set desired_mechs,

@@ Line 69: / Line 69: @@
      const char *value;
  } gss_cred_store_element, *gss_cred_store_element_t;
- typedef const struct gss_cred_store_element gss_const_cred_store_element_t;
+ typedef struct gss_cred_store_element gss_cred_store_element_t;
  typedef struct gss_cred_store_struct {
      OM_uint32 count;
-     gss_const_cred_store_element_t *elements;
+     gss_cred_store_element_t *elements;
  } gss_cred_store, *gss_cred_store_t;
  typedef const struct gss_cred_store_struct *gss_const_cred_store_t;

@@ Line 47: / Line 47: @@
 Same as above, but can target a specific mechanism.  The credential store need not be mechanism-specific and remains abstract.
-=== gss_strore_cred_into() ===
+=== gss_store_cred_into() ===
 This is analogous to gss_cred_store() except that a specific credential store can be specified (in the krb5 case, generally a ccache file).

@@ Line 5: / Line 5: @@
 == Background ==
-During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy.
+During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy.  Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same process environment as the proxied application, and may run multiple concurrent tasks on behalf of different applications with different trust/credentials.
-A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism specific, as the proxy tries to be mechanism agnostic as much as possible.
+A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism-specific, as the proxy tries to be mechanism-agnostic as much as possible.
 In this light a 'Credential Stores' Extension has been [http://www.ietf.org/mail-archive/web/kitten/current/msg03013.html proposed] on the Kitten IETF Mailing list.
@@ Line 14: / Line 14: @@
 * Abstract interface to pass credential store configuration to GSSAPI mechanisms.
-* The credentials need to be specified in configuration files so no security sensitive information (like passwords) must be exposed there.
+* The credentials need to be specified in configuration files, so security sensitive information (like passwords) must not be exposed there.
-* Mechanisms can define their own key/value pairs
+* Mechanisms can define their own key/value pairs.
-* New Key/Value pairs can be easily added in future
+* New Key/Value pairs can be easily added in future.
-* The actual API need not to know how to interpret Key/Value pairs, they are passed directly to mechanisms
+* The mechglue need not to know how to interpret key/value pairs; they are interpreted only by mechanisms.
 == Architecture ==
-The exposed public functions are paired with an analogous one in the mechglue SPI to give mechanisms access to the Credentials Store.
+The exposed public functions are paired with analogous functions in the mechglue SPI to give mechanisms access to the Credentials Store.
-The implementation provides functions only for mechanisms for which it makes sense, initially krb5 but not SPNEGO
+The implementation provides functions only for mechanisms for which it makes sense--initially krb5 but not SPNEGO.
 == New APIs ==
@@ Line 35: / Line 35: @@
 * gss_cred_store_struct
-If the cred store structure does not contain a mechanism specific configuration for the mechanism at hand, the usual defaults are applied.
+If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied.
-=== gss_aqcuire_cred_from() ===
+=== gss_acquire_cred_from() ===
-Acquires new credentials using the provided store. The store can specify both the actual credentials and/or the credential cache.
+Acquires new credentials using the provided store.  The store can specify both the actual credentials and/or the credential cache.
-In the Krb5 mechanism case it could specify a keytab and a ccache location.
+In the krb5 mechanism case it could specify a keytab and a ccache location.
 === gss_add_cred_from() ===
-Same as above but can target a specific mechanism. The credential store need not be mechanism specific and re mains abstract.
+Same as above, but can target a specific mechanism.  The credential store need not be mechanism-specific and remains abstract.
 === gss_strore_cred_into() ===
-This is analogous to gss_cred_store() except that a specific credential store can be specified (In the krb5 case generally a ccache file).
+This is analogous to gss_cred_store() except that a specific credential store can be specified (in the krb5 case, generally a ccache file).
 === gss_cred_store_element_struct ===

@@ Line 36: / Line 36: @@
 * gss_cred_store_struct
-If the cred store structure does not contain a mechanism specific configuration for the mechanism at hand gthe usual defaults are applied.
+If the cred store structure does not contain a mechanism specific configuration for the mechanism at hand, the usual defaults are applied.
@@ Line 62: / Line 62: @@
 A counter and an array of elements.
 == C bindings ==