• Author: NT
• Status: Draft
• Associated Issue: http://www.mantisbt.org/bugs/view.php?id=4235

There are lots of requirements to support extra authentication methods, and lots of patches supplied against various different releases to add an authentication method.

We need a means of adding an Authentication method that does not need to patch core functionality. Setting up a system of plugins for authentication would be the best way to acheive this.

The existing authentication methods (e.g. LDAP, HTTP) need refactoring to become plugins.

Anonymous authentication needs to be as simple as enabling a plugin, which would then create the required anonymous user (if not already existing).

We should be able to take credentials from other active logins (e.g. a cms token,http or X.509 authentication) and use that to automatically login (and reauthenticate ?) the user without asking them to supply another set of credentials.

Once we have authenticated we should be able to use our credentials to automatically sign the user into another system (e.g. a wiki).

Authentication systems which use credentials other than userid/password should be able to add a form to the login/reauthentication/signin pages for their credentials (e.g. openid url). They may also be required to display a different page instead.

Plugins should have a means of specifying their priority. We would wish to check for methods that require fetching no extra resources (Anonymous user or X.509) first, then those which require database accesses, and finally those that require fetching an external resource (e.g. LDAP, CAS).

Plugins could be allowed to deny a request authorised by an earlier executing plugin.

Plugins may need to fill in missing credentials for later plugins to check against (e.g OpenId plugin to supply userid that the url relates to, or http plugin to supply userid (and password ?).

Plugins should be able to be marked as protected, to prevent users from accidentally removing access to their site.

There should be a plugin configuration page which plugins can override to add extra fields as needed.

The signup process should be able to be configured so that it does not have to send a confirmation email, as this is a problem for some sites.

• The new plugin and event system should be used to implement this if possible.
• events of type chain should be used.
• plugin events will need to be called in a configurable order.
• Installation could be problematical. The current schema update page is displayed after a link is clicked on the front page. The plugins are loaded before page headers are output so that header events can be fired. if the plugin tables do not exist (plugin system problem), or do exist but need some extra fields (pluggable authentication problem), there will be a dataase error before the schema can be upgraded.
• check login events to be passed username, password, already_verified flag, and userid (if known).
• usually if already_verified is set plugin will just pass these parameters to the next in the chain unchanged.
• when all the events have been processed the user will be logged in if already_verified is true, otherwise the current error message will be displayed.

• Please provide feedback