Difference between revisions of "Projects/Credential Store extensions"
m (→New APIs) |
|||
Line 5: | Line 5: | ||
== Background == |
== 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. |
− | Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same security context as the proxied application and it 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 |
+ | 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. |
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. |
* Abstract interface to pass credential store configuration to GSSAPI mechanisms. |
||
− | * The credentials need to be specified in configuration files so |
+ | * 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 |
+ | * The mechglue need not to know how to interpret key/value pairs; they are interpreted only by mechanisms. |
== Architecture == |
== Architecture == |
||
− | The exposed public functions are paired with |
+ | 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 |
+ | The implementation provides functions only for mechanisms for which it makes sense--initially krb5 but not SPNEGO. |
== New APIs == |
== New APIs == |
||
Line 35: | Line 35: | ||
* gss_cred_store_struct |
* gss_cred_store_struct |
||
− | If the cred store structure does not contain a mechanism |
+ | If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied. |
− | === |
+ | === 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 |
+ | In the krb5 mechanism case it could specify a keytab and a ccache location. |
=== gss_add_cred_from() === |
=== gss_add_cred_from() === |
||
− | Same as above but can target a specific mechanism. The credential store need not be mechanism |
+ | 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_strore_cred_into() === |
||
− | This is analogous to gss_cred_store() except that a specific credential store can be specified ( |
+ | 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 === |
=== gss_cred_store_element_struct === |
Revision as of 15:19, 4 May 2012
This project is about adding a set of extensions to GSSAPI to more easily handle credentials in a mechanism agnostic way.
Contents
Background
During the development of the 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.
In this light a 'Credential Stores' Extension has been proposed on the Kitten IETF Mailing list.
Requirements
- Abstract interface to pass credential store configuration to GSSAPI mechanisms.
- 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.
- New Key/Value pairs can be easily added in future.
- 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 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.
New APIs
Functions:
- GSS_Acquire_cred_from()
- GSS_Add_cred_from()
- GSS_Store_cred_into()
Structures:
- gss_cred_store_element_struct
- 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.
gss_acquire_cred_from()
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.
gss_add_cred_from()
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).
gss_cred_store_element_struct
A urn/value pair. Example: URN = 'ccache' Value = 'FILE:/tmp/somecc'
gss_cred_store_struct
A counter and an array of elements.
C bindings
/* Extension for credential stores */ typedef struct gss_cred_store_element_struct { const char *urn; 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_struct { OM_uint32 count; gss_const_cred_store_element_t *elements; } gss_cred_store, *gss_cred_store_t; typedef const struct gss_cred_store_struct *gss_const_cred_store_t;
#define GSS_C_NO_CRED_STORE ((gss_const_cred_store_t) 0)
OM_uint32 gss_acquire_cred_from( OM_uint32 *minor_status, const gss_name_t desired_name, OM_uint32 time_req, const gss_OID_set desired_mechs, gss_cred_usage_t cred_usage, gss_const_cred_store_t cred_store, gss_cred_id_t *output_cred_handle, gss_OID_set *actual_mechs, OM_uint32 *time_rec);
OM_uint32 gss_add_cred_from ( OM_uint32 *minor_status, const gss_cred_id_t input_cred_handle, const gss_name_t desired_name, const gss_OID desired_mech, gss_cred_usage_t cred_usage, OM_uint32 initiator_time_req, OM_uint32 acceptor_time_req, gss_const_cred_store_t cred_store, gss_cred_id_t *output_cred_handle, gss_OID_set *actual_mechs, OM_uint32 *initiator_time_rec, OM_uint32 *acceptor_time_rec);
OM_uint32 gss_store_cred_into( OM_uint32 *minor_status, gss_cred_id_t input_cred_handle, gss_cred_usage_t cred_usage, const gss_OID desired_mech, OM_uint32 overwrite_cred, OM_uint32 default_cred, gss_const_cred_store_t cred_store, gss_OID_set *elements_stored, gss_cred_usage_t *cred_usage_stored);