ability for secure site to allow LDAP authentified users to login via HTTP-Auth

The secures site module calls user_module_invoke to login the user. This function calls hook_user in all modules. As this is the hook I think other authentication modules would use to integrate into drupal it should work.

I would recommend getting the LDAP module working before enable the secures site module and if it still does not work then please reopen this issue and then we can investigate further.

In the user.module user_login_validate is called first. This function calls the user_authenticate. This is were the user is authenticated and were hook_auth</cdoe> is called. Then <code>user_login_submit is called and this is were hook_user is called. This is for users that are already logged in and hook_user('login'...) is for modules to act on the event of a successful login.

The way securesite works is that it calls user_authenticate first then if successful user_module_invoke is called. I have changed this a little in a patch by calling user_login_submit.

Please test this. I don't see why this should not work.

Also make sure your user roles have the correct permissions "access site", else secures site will not allow them to login.

How is your PHP installed is it as an Apache module or as CGI. Have a look at this issue http://drupal.org/node/28408

And maybe try using the html login form to login and see if you are able to login. If you are then it most likely is a PHP CGI issue.

Here is my version of the patch for the same problem.

I added a call to _ldap_authenticate before trying to call user_authenticate, if the function exists. They both return exactly the same thing.

I still have some problems with this though, it was working in our dev environment, but it does not work when brought live.
I'm still trying to get to the bottom of it.

Oh. and i put this in the code comment, but not in the issue update:

ldap auth uses submit handlers on the login forms to log in. It does not use the drupal auth system.
It does this because it doesn't require the username@service.com format.

I tried following the ldap modules authentication process and from what I can tell it does not use hook_auth to authenticate the user. I don't know why. That is where I would start with a external auth module. You say it is because it does not require the username@service.com format but by bypassing the drupal auth system it makes it very difficult to support as it does not play nice with others.

Calling _ldapauth_user_authenticate is a little bit of a hack but I cant see a way around it with the way ldap is structured.

This is the flow of things as far as I can tell.

 ldapauth_form_alter($form_id, &$form) ( set '#validate' = 'ldapauth_login_validate' )
 |
 |
 |_   ldapauth_login_validate($form_id, $form_values) (called on login form submit)
 |
 |
 |_   _ldapauth_user_authenticate ( check local user first else ... )
       |
       |
       |_   _ldapauth_ldap_login
              |
              |
              |_   ldapauth_auth (if return $ok = true)
              |
              |
              |_   return $user; 

function that set global $user
ldapauth_login_validate
_ldapauth_user_authenticate

Thanks for working on this, NaX. Why don't we set this issue to "won't fix" and submit a bug report to the LDAP Integration module?

Darren , there is no way the ldap auth module can work any other way. because drupal's auth system simply isn't flexible enough to do it any other way.

To avoid having the optional support for ldap auth (which i don't think is that much of a hack, i mean lots of programs / modules add support for other modules), perhaps securesite should add it's own auth hook, which can then be added to ldap. But i think is even more of a hack than just having an if function_exists().

Lots of modules optionally extend others.

I don't understand why ldap cant use hook_auth. They could set the $user variable and return TRUE/FALSE with hook_auth, maybe theirs more to it that I am just not seeing.

But you are correct. It is not that big a deal to include conditional support for the ldap module. The only problem for me is that it shouldn't need to be this way, if their are already structures in place to handle these kind of things. If a hook or api did not exist then I would understand but when their are ways to integrate and play nice with others then I don't.

I am going to dig a little deeper into the ldap module to understand better, until then I will have to disagree. I will also look at creating a patch for now for people that need it but I don't know if it should be committed.

My big problem is testing, I don't have a ldap server to test against. Hopeful someone else can help with that.

From what I can tell the patch submitted by adrian should work just fine (comment #7).

Only thing is that the ldap module has been re-written and the HEAD version is very different to 4.7. The auth method is still using the same workaround, but many of the function names have changed.

4.7
_ldapauth_user_authenticate($form_values['name'], trim($form_values['pass']));

HEAD
_ldap_integration_code_changed_login_validate($form_values['name'], trim($form_values['pass']));

This will affect the patch depending on the version of ldap you use.

@aclight have you tested adrian's patch.

I also did some digging, and from what I can find ldap decided not to use the authmap method (hook_auth) for integrating. What ldap does is when a user first authenticates on the ldap server then it saves that user using the normal user_save function. But I have not yet found a reason for them dropping the authmap method. Still digging.

That is a strange error. The error is triggered by the LDAP Module, but maybe it is something we are doing that is causing it.

Try this. I swapped the 2 round in adrian's patch. Now it will check local accounts first if that fails it will check ldap. I don't know exactly what would be the best way round. Maybe we should not query local accounts at all if ldap is enabled.

  $account = user_authenticate($edit['name'], $edit['pass']);
  /**
   * Attempt to log in using the LDAP auth module.
   * The LDAP auth module does not use Drupal's authentication system,
   * but instead adds a submit handler to the user login form.
   *
   * This is done to not require the username @ service.com format
   */
  if (function_exists('_ldapauth_user_authenticate') && !$account) {
    $account = _ldapauth_user_authenticate($edit['name'], $edit['pass']);
  }

  if ($account->uid && user_access('access site', $account)) {
    // login successful

I'm a little stumped on this error you are getting. Are you using latest version of the ldap module?

Your modification of my code was correct. I did leave out the uid.

ldap users might wish to use mod_ldap and webserver_auth module from contrib

@moshe: IINM, webserver_auth and mod_ldap will only allow LDAP users to authenticate. Some users (me included) need to have users from LDAP plus users created in the Drupal setup.

@aclight: Will you please check your authmap table to see what other rows use your username? That could help us find the root cause of that error.

@aclight: The error message indicates that ldap_auth is trying to add yor username into the authmap table, but can't because an entry already exists. So, I'd like to know the existing entry in the table.

@aclight: Yep, we're not understanding each other. In comment #16, you got an error message saying there was data in the authmap table of your database that prevented the ldapauth module from adding details about your login (which you call "username"). I would like to know what details are in the database already for your account ("username"), so we can tell which module added them and find out why you're getting that error message.

In other words, look at the authmap table in your database and tell us the data associated with the row with uid = your uid ("username").

OK. No worries.

Hi, I'm having the exact same issue as the poster above. I can use securesite but only with "real" users in the drupal database. It does not work with users who are being authenticated via ldap integration.

I'm using 5.1 and the latest HEAD of everything.

I'm using the following code successfully:

  if (!$account->uid) {
    $account = user_authenticate($edit['name'], $edit['pass']);
  }

  /**
   * Attempt to log in using the LDAP auth module.
   * The LDAP auth module does not use Drupal's authentication system, 
   * but instead adds a submit handler to the user login form.
   *
   * This is done to not require the username@service.com format
   */
  if (function_exists('_ldapauth_user_authenticate') && !$account->uid) {
    $account = _ldapauth_user_authenticate($edit['name'], $edit['pass']);
  }

  if ($account->uid && user_access('access site', $account)) {
    // login successful

Here's the code in patch form.

OK, I spoke too soon. Using this code, ldap_auth tries to connect to example.com to authenticate! It eventually connects to the correct server and authenticates, but it takes several minutes. This happens because ldap_auth must not be getting the correct LDAP information from the database and it primes the server variable to example.com. I'm still looking for a solution.

@NaX: From what I can tell, ldap_auth doesn't implement hook_authenticate() because they allow admins to set it up so users authenticate only against the LDAP DB and not Drupal's DB. In user_authenticate(), Drupal first checks the local database, then checks for external auth. And the external auth checks depend on having a server as part of the username, which, as adrian mentioned, the LDAP module also doesn't require.

@Junyor: From what I can tell when ldap is setup correctly and working the patch works just fine. Is that also your findings? A while ago I spent a lot time trying to follow the ldap modules processing to see how best we could integrate. I got very lost but yes you are correct as far as I can tell, the ldap module does not use hook_authenticate().

I think we need to find a way to check if the ldap module is installed and setup, rather than just checking if the function exists. If it is setup then we call _ldapauth_user_authenticate.

Alternately we can have a secure site setting to enable or disable ldap integration. So admins can choose to enable ldap integration only when the ldap module is setup and working.

Sorry for all the updates. I found the problem. The proposed patch always calls user_authenticate, then _ldapauth_user_authenticate. ldapauth has a function called ldapauth_auth (AKA hook_auth), so user_authenticate calls ldapauth_auth, which bypasses the ldapauth initialization step. Here's the fixed patch which only calls user_authenticate when LDAP isn't enabled.

@NaX: I'm OK with the current setup, it's just that the code wasn't correct. So, no, it doesn't work correctly with the previous patch. LDAP would always try to authenticate via example.com because _ldapauth_init wasn't called. I guess when the call to user_authenticate failed, securesite then called _ldapauth_user_authenticate, which worked and the user was logged in.

The issue with ldapauth_auth is discussed in http://drupal.org/node/158671.

Patch from #37 committed to the DRUPAL-5 branch.