Per Domain Authentication

Maia 1.0 only supports one authentication method for the whole site. However, real life has demonstrated a need for more flexibility, such as different POP servers for different domains. We need a more modular approach and more flexibility to the authentication process. In the process, we will do away with the confusing $address_rewriting_type configuration option, and also allow fall-through to other authenticators, all through a more intuitive web interface.


The new controls will allow each domain to specify what authentication mechanisms to use. Within each mechanism are options specific for that method, such as pop3 hostname, etc.

Each mechanism can return a failure mode that determines what do do next:

  • REJECT - If the authentication fails, stop processing and reject the Maia login
  • DUNNO - If the authentication fails, process the next authenticator. Fall back to the @. default if this is the last one in the domain
  • ACCEPT - Accepts all logins. Probably only useful for debugging or emergencies.

Note how we can also do a fallback to the system default (@.) domain if a specific record is not found for the login.

Finally, a set of regexes will help mold the login to replace the $address_rewriting_type functionality. This won't require much regex skill for common cases, but will allow for some more unusual cases. We may even make a php function callback that can be used for extremely weird cases. Possible security risk there, so it may need inspection.

Standard Login

An new standard is being made now: We expect all logins to be the full email address, and they are stored in maia_users as a full email address. For systems where a simple username is preferred, an option can be used to automatically tack on a domain. I don't think this is an unreasonable approach, because Maia is inherently designed to filter email - there must be an email address associated with every user!

New web interface

In the admin page for each domain, we will add a display of current authentication options for the domain, and also controls to reorder, modify and add/delete authentication options. Built into the interface is some warnings when the configuration may do unexpected things, such as having two REJECT modes (only the first will be tried). It will also show the system default (@.) settings when the last mode is DUNNO.

Domainsettings page

authsettings page

Regex to replace $address_rewriting_type

A couple of configurable regex's also allow the login input to be transformed before sending to the authentication system, and then transformed again to match to a maia_user record.

  • Login: user@…
    • regex = s/^(.*)@(.*)$/\1/
    • result: "user"
  • Routing adress for maia internal
    • this applies to login for methods that do not return a modified result, or to the returned result from methods such as sql or ldap)
    • regex = s/^(.*)@(.*).(.*)$/\1_\2_\
    • result: "user_example_com@…"


First, consider a new table to store config items for each domain:

CREATE TABLE `maia_auth` (
`conf_key` VARCHAR( 100 ) NOT NULL ,
`conf_value` VARCHAR( 255 ) NOT NULL ,
`priority` SMALLINT NOT NULL ,
PRIMARY KEY ( `id` )

Also, we have a subdirectory of authentication module files:

  your-weird-method.php  :)

These files should contain objects with methods to initialize and execute the authentication query. The initialization would accept a hash of values procured from the database table, queried one at a time by priority, until either success has been met, or it runs out of options.

The classes also provide reflective methods that return a description of required keys, so an admin screen can display needed information.

The authenticators will extend a common base class which will provide some common functionality.

Upgrade and Install considerations

For new installs, we can set up a default internal authentication and password for the @. user, and actually allow that user to be the superadmin. If this is the case, a check should be made during the authcheck process to make sure the superadmin password has been updated, and disallow any further use until it has been reset.

Existing data needs to be read from the config.php file and inserted into the @. authentication tables. For many installations, this will be all they have to do. Some installations that have made their own conditional settings in the config.php will break during the upgrade.

To keep upgrade paths reconciled with new installs, then we will also need the upgrade path to force the @. user and password change process too. (Need discusion here). This will help alleviate the possibility of the upgrade process breaking and leaving no way to log in. Do we need to? not sure if @. has to be superadmin... we can keep existing method...

Other considerations

When internal auth is in the authenticator chain, under what conditions do we show a change password screen? When we autocreate users, when do we issue an internal password?

An option int the internal auth mech could help determine this...

  • Show internal password box when:
    • Admin Only
    • If internal is first authenticator available (default)
      • users can override main auth method with internal auth
    • If internal password is already set
      • internal auth can be used as alternate, but only initiated by admin
    • Always
  • Admins can always see it, if the authenticator is defined.

feature request: "Only an Admin may create accounts? (Y/N) [N]" which makes login fail if there is no maia account to match. Note, an auth call may have to be made anyway, since we may not know what the maia account is until after the post-regex.

Do we allow a linked account to log into the account, or only in the case of accounts linked by ldap or sql answers?

  • I think no, because if an account is linked to an admin for some reason, you don't want to let them log in as admin
  • not sure about iff account is linked by sql or ldap AND Maia is already linked properly.
Last modified 15 years ago Last modified on Mar 28, 2008, 1:07:15 AM