Projects/Client principal selection - Revision history

Ghudson at 18:25, 12 October 2011

2011-10-12T18:25:01Z

Ghudson at 19:52, 8 September 2011

2011-09-08T19:52:13Z

Ghudson: /* Changes to the krb5_cccol implementation */

2011-09-05T14:13:03Z

‎Changes to the krb5_cccol implementation

Ghudson: /* krb5_cc_select API and pluggable interface */

2011-08-30T07:23:20Z

‎krb5_cc_select API and pluggable interface

Ghudson: /* krb5_cc_select API and pluggable interface */

2011-08-29T16:09:59Z

‎krb5_cc_select API and pluggable interface

Ghudson: /* GSSAPI behavior changes */

2011-08-22T16:19:23Z

‎GSSAPI behavior changes

Ghudson at 16:09, 18 August 2011

2011-08-18T16:09:42Z

Ghudson: /* GSSAPI behavior changes */

2011-08-16T04:33:46Z

‎GSSAPI behavior changes

Ghudson: /* k5identity module */

2011-08-15T20:45:58Z

‎k5identity module

Ghudson: /* krb5_cc_select API and pluggable interface */

2011-08-15T17:21:27Z

‎krb5_cc_select API and pluggable interface

← Older revision		Revision as of 18:25, 12 October 2011
Line 165:		Line 165:

	3. The application can acquire a credential with a specified principal name (or other name type which is converted to a principal name). In this case we will use krb5_cc_cache_match to find an appropriate cache within the collection.		3. The application can acquire a credential with a specified principal name (or other name type which is converted to a principal name). In this case we will use krb5_cc_cache_match to find an appropriate cache within the collection.
		+
		+	==Release notes==
		+
		+	End-user experience:
		+
		+	* Add the DIR credential cache type, which can hold a collection of credential caches.
		+	* Enhance kinit, klist, and kdestroy to support credential cache collections if the cache type supports it.
		+	* Add the kswitch command, which changes the selected default cache within a collection.
		+	* Add heuristic support for choosing client credentials based on the service realm.
		+	* Add support for $HOME/.k5identity, which allows credential choice based on configured rules.

← Older revision		Revision as of 19:52, 8 September 2011
Line 1:		Line 1:
−	{{project-~~review~~\|~~2011-08-26~~}}	+	{{project-rel\|1.10}}
−	{{project-target\|1.10}}

	This project's goal is to extend the core krb5 code to allow users to maintain credentials for multiple identities and for the GSSAPI client code to automatically select credentials based on the target service and hostname.		This project's goal is to extend the core krb5 code to allow users to maintain credentials for multiple identities and for the GSSAPI client code to automatically select credentials based on the target service and hostname.

@@ Line 104: / Line 104: @@
 ===Changes to the krb5_cccol implementation===
-The three "high-priority" caches (context default, environment default, and OS default) will be removed from the cache collection, so the cache collection iterates only over the per-type cursors.  Instead, following Heimdal's lead, the FILE type will yield the default ccache if it is of type FILE, in addition to its usual list.
+The three "high-priority" caches (context default, environment default, and OS default) will be removed from the cache collection, so the cache collection iterates only over the per-type cursors.  Instead, following Heimdal's lead, the FILE type will yield the default ccache if it is of type FILE, and will no longer yield the set of open file caches.
 There are three reasons for this.  First, it is inappropriate to include a default cache which has been overridden by another mechanism; for instance, kdestroy -A should not destroy the per-uid OS default file ccache if KRB5CCNAME has been set to something else.  Second, if the default ccache name is of type DIR:dirname, yielding the default ccache in addition to all of the subsidiary DIR::pathname ccaches would wind up duplicating the primary ccache.  Third, this change makes our behavior closer to Heimdal's, which is generally beneficial.

@@ Line 113: / Line 113: @@
   krb5_error_code krb5_cc_select(krb5_context context, krb5_principal server,
-                                 krb5_ccache *cache_out);
+                                 krb5_ccache *cache_out, krb5_principal *princ_out);
 This function will be backed by a pluggable interface with the following signature:
@@ Line 128: / Line 128: @@
   typedef krb5_error_code
   (*krb5_ccselect_choose_fn)(krb5_context context, krb5_ccselect_moddata data,
-                             krb5_principal server, krb5_ccache *cache_out);
+                             krb5_principal server, krb5_ccache *cache_out,
   typedef void

@@ Line 140: / Line 140: @@
   } *krb5_ccselect_vtable;
-Like server location modules, ccselect modules can return KRB5_PLUGIN_NO_HANDLE to defer to other modules.  If no module returns a value, the default cache will be used if it exists.  A module can return KRB5_CC_NOTFOUND if the proper client principal can be authoritatively established but no cache exists for it.
+Like server location modules, ccselect modules can return KRB5_PLUGIN_NO_HANDLE to defer to other modules.  If no module returns a value, krb5_ccselect returns KRB5_CC_NOTFOUND.
 A primitive form of hardcoded module ordering is present in the interface, to allow modules to declare themselves authoritative (reflective of deliberate configuration) or heuristic.  It will probably become desirable to allow admins to configure the module order.  This problem is deferred to the plugin framework, as it also applies to other pluggable interfaces which will likely exist within the framework (KDC location, kuserok).

@@ Line 162: / Line 162: @@
 . The application can acquire a credential with no name and pass that credential to gss_init_sec_context.  This case is complicated because RFC 2744 section 5.5 requires that if a default credential is queried and the resulting name exported, we get the same name as an acceptor would see on successful authentication using that credential.  This means we need to treat a default credential like the box in the Schroedinger's Cat experiment: as long as the application does not ask for the credential's name, we leave it undetermined until gss_init_sec_context time so that we can use krb5_cc_select.  If the application does ask, we resolve the credential's state to the default identity.
-Further complicating matters, the mechglue's gss_acquire_cred asks for the (first) mechanism's name immediately after acquiring credentials, which would prematurely collapse the waveform.  This code will have to be studied and a resolution found.
+Further complicating matters, the mechglue's gss_acquire_cred asks for the (first) mechanism's name immediately after acquiring credentials, which would prematurely collapse the waveform.  To resolve this, the mechglue will be changed to remove the auxinfo structure caching information in union creds.
 . The application can acquire a credential with a specified principal name (or other name type which is converted to a principal name).  In this case we will use krb5_cc_cache_match to find an appropriate cache within the collection.

← Older revision		Revision as of 16:09, 18 August 2011
Line 1:		Line 1:
−	{{project-~~early~~}}	+	{{project-review\|2011-08-26}}
	{{project-target\|1.10}}		{{project-target\|1.10}}

← Older revision		Revision as of 04:33, 16 August 2011
Line 155:		Line 155:

	===GSSAPI behavior changes===		===GSSAPI behavior changes===
		+
		+	The GSSAPI initiator code will be changed to use the cache collection. There are three cases to consider:
		+
		+	1. The most common case is that the application passes a null initiator cred handle to gss_init_sec_context. This case is relatively simple; we will use krb5_cc_select to choose a client identity from the collection.
		+
		+	2. The application can acquire a credential with no name and pass that credential to gss_init_sec_context. This case is complicated because RFC 2744 section 5.5 requires that if a default credential is queried and the resulting name exported, we get the same name as an acceptor would see on successful authentication using that credential. This means we need to treat a default credential like the box in the Schroedinger's Cat experiment: as long as the application does not ask for the credential's name, we leave it undetermined until gss_init_sec_context time so that we can use krb5_cc_select. If the application does ask, we resolve the credential's state to the default identity.
		+
		+	Further complicating matters, the mechglue's gss_acquire_cred asks for the (first) mechanism's name immediately after acquiring credentials, which would prematurely collapse the waveform. This code will have to be studied and a resolution found.
		+
		+	3. The application can acquire a credential with a specified principal name (or other name type which is converted to a principal name). In this case we will use krb5_cc_cache_match to find an appropriate cache within the collection.

@@ Line 146: / Line 146: @@
 ====k5identity module====
-The k5identity ccselect module consults a $HOME/.k5identity file ...
+The k5identity ccselect module consults a $HOME/.k5identity file to determine a client principal for the server principal.  If one is found, it attempts to find a cache in the collection matching the client principal.
 ====realm module====

@@ Line 118: / Line 118: @@
   typedef struct krb5_ccselect_moddata_st *krb5_ccselect_moddata;
   typedef krb5_error_code
-  (*krb5_ccselect_init_fn)(krb5_context context, krb5_ccselect_moddata *data);
+  (*krb5_ccselect_init_fn)(krb5_context context, krb5_ccselect_moddata *data,
   typedef krb5_error_code
@@ Line 138: / Line 141: @@
 Like server location modules, ccselect modules can return KRB5_PLUGIN_NO_HANDLE to defer to other modules.  If no module returns a value, the default cache will be used if it exists.  A module can return KRB5_CC_NOTFOUND if the proper client principal can be authoritatively established but no cache exists for it.
 ====k5identity module====
@@ Line 146: / Line 149: @@
 ====realm module====
-The realm ccselect module implements a simple realm heuristic.  If the realm of the server principal is known ...
+The realm ccselect module implements a simple realm heuristic.  If the realm of the server principal is known, the default cache and then the cache collection are searched for a client principal within the same realm.
 ===GSSAPI behavior changes===