Authentication and Authorization

The use of Cyrus IMAP may have a significant impact on the design, use and load of the current authentication and authorization infrastructure. In addition, authentication and authorization relates to both to security, and also, in the particular case of Cyrus IMAP, personal privacy.

Typically, an authentication and authorization database, such as for example LDAP, is already available and in use within an infrastructure. Cyrus IMAP would integrate with a variety of technologies, but a few considerations deserve outlining.

For example, when a user wants to set group permissions on an IMAP folder, the most intuitive attribute in LDAP to refer to the group is the Common Name (CN). This attribute however is not guaranteed to be unique. Uniqueness can be enforced within LDAP, although that may be too restrictive, and so the groups available in Cyrus IMAP can be limited to scope one, while the cn is used in the rdn (the cn is the naming attribute to compose the dn with); effectively enforcing uniqueness for those groups available to Cyrus IMAP.

Similarly, many deployments choose to use the mail LDAP attribute value as the mailbox name, while mail is a multi-valued attribute and is not configured to be enforced globally unique in the LDAP information tree under the root dn. In addition, attributes such as amilAlternateAddress and/or alias could potentially hold the same value as anyone’s mail attribute. These limitations or such implications become very clear when canonification of the authentication ID to the desired authorization ID is attempted.

For example, if <literal>jdoe</literal> is the login username, and Cyrus IMAP has a default realm configured <literal>example.org</literal>, the authentication ID becomes <literal>jdoe@example.org</literal>. It is this authentication ID, and not the supplied login username, that Cyrus IMAP uses to verify the credentials.

Cyrus IMAP thereafter allows authorization mechanisms, such as <emphasis>ptclient</emphasis> modules, to canonify the authentication ID to then ultimately return the authorization ID.

Suppose in the case of <literal>jdoe@example.org</literal>, where the authentication ID had been set, an LDAP module for ptloader could search LDAP for a <literal>uid=%U</literal> (where %U is the local part of the authentication ID), find the mail attribute value is <literal>john.doe@example.org</literal>, and authorize the user as such. Effectively, this enables Cyrus IMAP users to log in both with their username (uid) as well as their email address (or any of the aliases).

The process of client authentication and authorization

Client Authentication

The exchange and verification of identity information provided by a client, otherwise known as the process of authentication, provides a set of credentials that allow the server to verify that the user is in fact the user, and not an imposter.

Important

Authentication != Authorization

Authentication and authorization are two separate processes. Authentication is about verifying the credentials supplied by the client, while authorization is the process of determining what rights the client has. Authentication, logically, preseeds authorization.

The most common set of credentials is a username and password, but other forms exist like Kerberos v5 ticket exchange (for which, to obtain such, most often a password is supplied), or certificate based authentication (the secret keys for which are most often locked with a passphrase). In any case, authentication works based on a shared secret, and/or a trusted source for verification. Kerberos v5 works based on shared secrets (keytab), and certificate based authentication works based on shared, trusted sources for verification.

In the case of usernames and passwords though, the exchange and verification of the credentials is at the basis of its security. Sending plain text usernames and passwords over the wire would not allow any application to verify the source of the credentials is actually the user &ndash;who is supposed to be the only party to know the unique combination of username and password.

To obfuscate the login credentials, authentication can be encrypted with CRAM-MD5 or DIGEST-MD5, but this requires the server to have a copy of the original, plain text password. The password in this case becomes the shared secret.

Another method is to allow the plain text username and password to be transmitted over the wire, but ensure Transport Layer Security (TLS) or the more implicit Secure Socket Layer (SSL). The plain text password can now be used to compare it against a SQL database, bind to an LDAP database, attempt PAM authentication with, etc.

Users and Mailboxes

User mailboxes have a globally unique identifier which is not necessarily the same as the login name used. There are three distinguishable aspects to a user’s entity and the mailbox associated with it;

The user login credentials that are associated with the user authentication entity and verify the user is who the user claims to be.

For example, the user logs in with username <code>john.doe@example.org</code> and password <code>verysecret</code>.

The user’s authentication entity - with all attributes associated with it - can have one of those attributes be used to create the relationship between the user authentication entity on the one side, and the mailbox entity on the other side.

For example, the user that authenticated as <code>john.doe@example.org</code> may have a mailbox named <code>jdoe</code>.

The authorization entity, used to assign certain permissions to the user, uses the same attribute used to determine the mailbox name.

For example, the user that authenticated as <code>john.doe@example.com</code> and has mailbox <code>jdoe</code> needs an access control list entry on that mailbox that assigns <code>jdoe</code> certain rights on said mailbox.