[Dovecot] authentication documentation

[Timo Sirainen]

On Wed, 2004-08-11 at 03:27 -0400, Tom Metro wrote:
> http://dovecot.org/doc/auth.txt says:
> > Authentication is split into three parts: authentication mechanism,
> > password database and user database.
> 
> Which is good, except it never defines what "authentication mechanism" 
> really means, and how it is distinct from how the password is stored.

How about:

http://wiki.dovecot.org/moin.cgi/Authentication

> > # Space separated list of wanted authentication mechanisms:
> > #   plain digest-md5 anonymous
> > #
> > # All IMAP/POP3 clients support plain-authentication. Digest-MD5 is more
> > # secure, but it's not widely supported by clients. Note that by default
> > # plaintext authentication is disabled unless SSL is used - see
> > # disable_plaintext_auth setting.
> > auth_mechanisms = plain
> 
> Here too, I think it would be useful to define "authentication 
> mechanisms", but you should probably first provide a better definition 
> for "Authentication processes." Though the term "process" makes me think 
>   that we're talking about an executable. But I guess it is defining the 
> behavior of a child process - right?

Yes. Although it's also in a separate executable, but there can be
multiple processes.

> Perhaps:
> 
> ##
> ## Authentication processes
> ##
> 
> # An Authentication process is a child process used by Dovecot that
> # handles the authentication steps. The steps cover an authentication
> # mechanism (auth_mechanisms, how the client authenticates in the IMAP
> # protocol), which password database should be queried (auth_passdb),
> # and which user database should be queried (auth_userdb, to obtain
> # UID, GID, and location of the user's mailbox/home directory).
> #
> # You can have multiple processes, though a typical configuration will
> # have only one. Each time "auth = xx" is seen, a new process
> # definition is started. The point of multiple processes is to be able
> # to set stricter permissions. (See auth_user below.)
> #
> # Just remember that only one Authentication process is asked for the
> # password, so you can't have different passwords accessible through
> # different process definitions (unless they have different
> # auth_mechanisms, and you're ok with having different password for
> # each mechanisms).

Looks good. I'll use that, except use IMAP/POP3 there.

> (What is the order in which Authentication processes are chosen, if say, 
> you have multiple defined for the 'plain' auth_mechanisms? Or is that 
> considered a configuration error?

The order is unspecified. Dovecot will just chose one of them. With 0.99
multiple auth processes is quite pointless really. 1.0-tests support
fallbacking to next process if first one fails.

That's also why I haven't really bothered to update 0.99's
documentation. It makes less sense and once 1.0 is finished it has to be
changed anyway. In Wiki I started to write about 1.0 already though..

> # Specifies how the client authenticates in the IMAP protocol.
..

Also looks good.

> # cram-md5 as the communication is already encrypted. Note that by
> # default plain text authentication is disabled unless SSL is used -
> # see disable_plaintext_auth setting.
> auth_mechanisms = plain
> 
> (I thought by default disable_plaintext_auth=no. Has that changed?

Right, it's no in 0.99. I've changed it to yes in 1.0-tests.

> My assertion, "the password can be encrypted by Dovecot to match any of 
> the encryption schemes used in password databases," may not be accurate. 
> Your comments seem to imply that Dovecot won't translate a plain 
> password to a digest-md5 storage scheme (perhaps also cram-md5), though 
> it seems this should be possible.)

It's possible. I added "(or be in plaintext)" there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040816/6a5eb503/attachment-0001.bin>