Next: The LOGIN mechanism, Previous: The ANONYMOUS mechanism, Up: Mechanisms [Contents][Index]
The PLAIN mechanism uses username and password to authenticate users. Two user names are relevant. The first, the authentication identity, indicates the credential holder, i.e., whom the provided password belongs to. The second, the authorization identity, is typically empty to indicate that the user requests to log on to the server as herself (i.e., the authentication identity). If the authorization identity is not empty, the server should decide whether the authenticated user may log on as the authorization identity. This is typically used for super-user accounts like ‘admin’ to take on the role of a regular user.
In the client, this mechanism is always enabled, and require the
GSASL_AUTHID
and GSASL_PASSWORD
properties. If set,
GSASL_AUTHZID
will also be used.
In the server, the mechanism is always enabled. Two approaches to authenticate and authorize the client are provided.
In the first approach, the server side of the mechanism will request
the GSASL_VALIDATE_SIMPLE
callback property to decide whether
the client should be accepted or not. The callback may inspect the
GSASL_AUTHID
, GSASL_AUTHZID
, and GSASL_PASSWORD
properties. These property values will be normalized.
If the first approach fails (because there is no callback or your
callback returns ‘GSASL_NO_CALLBACK’ to signal that it does not
implement GSASL_VALIDATE_SIMPLE
) the mechanism will continue to
query the application for a password, via the GSASL_PASSWORD
property. Your callback may use the GSASL_AUTHID
and
GSASL_AUTHZID
properties to select the proper password. The
password is then normalized and compared to the client credential.
Which approach to use? If your database stores hashed passwords, you have no option, but must use the first approach. If passwords in your user database are stored in prepared (SASLprep) form, the first approach will be faster. If you do not have prepared passwords available, you can use the second approach to make sure the password is prepared properly before comparison.
The PLAIN mechanism was initially specified in RFC 2595 and later revised in RFC 4616.
Next: The LOGIN mechanism, Previous: The ANONYMOUS mechanism, Up: Mechanisms [Contents][Index]