Password sync plugin, and questions about plugin criticality

[Nicolas Williams]

On Mon, Jun 26, 2006 at 01:33:38AM -0400, Ken Hornstein wrote:
> void pwupdate_init(void **context, krb5_context);

No krb5_context should be needed.  One argument should suffice.

Presumably it's up to the plug-in to be thread-safe.

> int pwupdate_precommit_password(void *context, char *password, int pwlen,
> 				char *error_msg, int error_msg_len);
> 
> 	Update the password in the external store; called before password
> 	is stored locally.  In case of failure, return non-zero code and
> 	set error_msg to an error string.

This mixes password quality checking and password updates.

For a password synchronization hook this is not a good thing.

Besides, a generic password quality checking function needs to take G11N
into account, which means taking a list of language tags (languages
spoken by the user) and outputting Unicode strings (UTF-8, preferably).

Also, keep in mind that Larry wants some well-known password quality
codes for use in the new set/change password protocol and we've agreed
to provide such codes, so a password quality check function should
optionally output them.  The point of these codes is to allow for
client-side L10N.

> int pwupdate_postcommit_password(void *context, char *password, int pwlen,
> 				 char *error_msg, int error_msg_len);
> 
> 	Same as the precommit function, but called after password is stored
> 	locally.

Same comment.

Also, if you separate password quality checking from password
synchronization you can collapse these two functions into one.

Basically I think password quality checking in a situation like this
should be done independently at the KDC (kadmind) and, if password
changing is allowed on other systems then there as well.

If a given password would pass the quality policy at one system but
would not pass the other's then force the synchronization password
change anyhow (presumably you can't make the two [or more] policies
agree entirely due to diverging capabilities of different systems).

I can't see any reason to combine the two functions (quality checking
and synchronization) other than an inability to force password changes
through synchronization.  If that's the case at all then that should be
stated as a design constraint.

Nico
--