[kmf-discuss] PROPOSAL: certificate to name mapping

[Wyllys Ingersoll]

Jan Pechanec wrote:

[...]
> 	kmf_map_cert_to_name_init(KMF_HANDLE_T, KMF_ATTRIBUTE *);
>
> 	- for initializing the mapping if the mapping is not defined in the 
> policy file or if we want to override. It would dlopen() the mapper module. 
> Attributes:
>
> 		- mapper name (would look for, say, kmf_mapper_<name>.so)
> 		- directory (if .so not in, say, /etc/security/kmf)
> 		- full mapper path (if one want to use, say, /tmp/xxx.so)
> 		- mapper specific configuration in a string, see below.
>
> 	about mapper configuration - we can hardly come up with the complete 
> set of various keywords that could be individually set using kmfcfg(1). By 
> keyword I mean "ignorecase", "ignoredomain", "mapperfile", etc. So, why not 
> to use one attribute that would cover the configuration? The value of 
> mapper-cfg would be specific to the module, while common keywords would be 
> expectable:
>
> 	mapper-cfg="ignorecase=yes,ignoredomain=yes,debug=yes"
>
> 	we should probably even omit "yes"/"no" part completely. In the 
> policy file, it would be like this, for example:
>
> <cert-to-name-mapping
> 	mapper-name="email" 
> 	mapper-cfg="ignorecase,ignoredomain">
>   

Just to be clear - this  new "cert-to-name-mapping" configuration info 
would be attached to
a policy and defined in the kmfpolicy.xml file?  This implies that we 
also have to update
kmfcfg to support adding this to a policy. 

The mapper-cfg value will have to be pretty wide-open, though we should 
limit it to
a fixed set of characters and a max size (256 characters?).    The 
consumer of the mapper-cfg
will be the mapper itself, so we cannot really know what will be put there
aside from our what our own modules will require.

> 	every mapper could (I hope) provide just one function, that would be 
> used from this KMF API call:
>
> 	kmf_map_cert_to_name(KMF_HANDLE_T, KMF_DATA *cert);
>   

What about the reverse - should the mapper also provide a way to find
all of the certs for a particular user?  I guess one could construct
that function in KMF by just calling kmf_map_cert_to_name for each
cert returned by "kmf_find_cert" and matching to the desired name, so
maybe the mapper doesn't need to provide this.

The name object returned should probably be a generic KMF_DATA block
and not just a single "char *".  I can envision a mapper that
returns some sort of structure of data (struct passwd, for example)
instead of just a single name string.



> 	this would use the mapping set by kmf_map_cert_to_name_init() or 
> default mapping from the policy file. Otherwise, the function would fail.
>
>
> 	the mapper function itself could be using KMF calls but would not 
> read the policy at all; it would get all needed data through function 
> arguments. Remember we could be overriding the policy settings.
>   

Yes.

> 	if this would be OK, we could specify what mappers we would want to 
> ship with it. We could even use pkcs11_pam stuff for now, it would be opaque 
> to the user. I think that usually mapper-cfg wouldn't be used at all if we 
> provide reasonable defaults (ignorecase for most of the mappers, for 
> example, so "dontignorecase" would be acceptable by the module). Also, I 
> would prefer more simpler mapper modules than few complex ones.
>
> 	what do you think?
>   

I think it sounds reasonable so far, we need to think about the details. 

Also, what mappers would we provide initially?


-Wyllys