Problem

Currently, webserver authentication only checks if a user is logged in, but not which user is logged in. Since externally authenticated user can change without Drupal's involvement, the authenticated user should be validated against the current session on each page load. As this check is performed for current sessions, care should be taken so that the module's default behavior allows users to remain logged in when the module is first enabled.

Solution

Since the external username may differ from the Drupal username (linked via authmap), a session variable caching the externally authenticated user should be used to validate that the current session and the external user match. If they don't match, the current session should be ended, and a new login attempted. If the new login fails (or the authname is empty), the session should be anonymous.

To make this user validation work, a new configuration option to match external usernames against existing Drupal usernames (and create authmap entries, enabled by default) would ensure that the user who enables the module isn't immediately logged out and unable to log back in. An admin can then disable the option if desired, and the newly created authmap entry would ensure they remain logged in. The option should be clearly visible in the module configuration page -- however, since this module currently trumps all other authentication modules, it makes sense that existing users should be matched by default to ease migration to external authentication.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sshambar’s picture

Attached patch to validate session against external username, and add setting to match against Drupal username if authmap is missing by default and adding any missing authmap entry so that the option can be disabled later without preventing user future logins.

sshambar’s picture

To reproduce the problem in existing code:

  1. enable module (if not already)
  2. login with a known working username (eg admin)
  3. navigate to a restricted area (eg module configuration)
  4. change external login - for example, if using Apache basic auth, quit and restart browser, and enter new (less privileged) login (eg regular user)
  5. continue to navigate to restricted area (drupal session is still using old credentials)

To test the patch:

Repeat the steps above. The last step above would re-authenticate the session, and lead to correct access checks.

sshambar’s picture

Status: Active » Closed (fixed)

Merged into dev branch, thanks!