Pasword quality pluggable interface project review
Nicolas.Williams at oracle.com
Mon Aug 30 19:31:54 EDT 2010
On Mon, Aug 30, 2010 at 07:12:54PM -0400, Greg Hudson wrote:
> On Mon, 2010-08-30 at 18:22 -0400, Sam Hartman wrote:
> > I can understand deferring revising our set-change password support.
> > However, as Russ pointed out, the existing change protocol has a way for
> > a text error to come back--Heimdal does that. I think we need to at
> > least support this in the plugin interface even if you don't write the
> > glue now to make it work.
> So, my concern about doing it now is that we'll do it wrong now and have
> no way of knowing it until later.
There's a user on the client side. They can read text [provided it's
localized]. Text is all they need. As evidence I offer my experience
with web-based password change pages:
All web-based password change interface I've ever used (sadly, I've used
many) use text to describe password quality policies. Some also use
any, is sent by the server.
We only need a policy code when the server can't send HTML + scripts to
the client, and even then it's not a big deal to use a "generic" code if
we can show the user some text [in a language they can read].
So, what could we be missing, besides lang tags and generic text? Two
1) A way to get a list of policy codes to be "enforced" by the client (if
there's a smart client). That is, the client start by getting a list
of policy codes and a [localized text description of all policies in
effect] from the server.
We almost certainly don't care about (2) here. So, really, just (1).
> Here's the simplest proposal I can imagine for including this support in
> the plugin API:
> * Add a new error code KADM5_PASS_Q_GENERIC.
> * Add the following arguments to the check method:
> - const char **languages: null-terminated list of client language tags
> or NULL
Or make it a comma-separated list of lang tags. Then it can be a const
> - char **language_out: language chosen by plugin, or NULL (memory
> allocated by module; we can't simply point into languages because fuzzy
> matches are a possibility).
The chosen lang tag is not that important. It's not needed for
rendering, and the user will be able to figure it out by themselves.
> - char **errmsg_out: error message from plugin or NULL (memory
> allocated by module).
Yes. Or you could just provide one big buffer... Since you'll
eventually run into a type of plugin where module-allocated outputs are
unavoidable you might as well address this now.
> * Add a new method to free *language_out and another new method to free
> *errmsg_out. Or perhaps just one method to free a module-allocated
> By contrast, if we ignore the problem now, here's what we have to do
> later when we're prepared to fully handle it:
But the errmsg_out can be used _now_. No need for a new protocol for
that. It'd be very odd to have a plugin that fails a password without
giving the user any guidance whatsoever as to what they did wrong.
> As a general rule, I believe it's better to be prepared to change later
> than it is to half-accomodate future requirements now.
errmsg_out is a requirement now.
More information about the krbdev