Patch to add single sign on and seamless SSO to ldap_authentication

I merged this on my server and in the process cleaned up alot of the _ldap_authentication_user_login_authenticate_validate() function. Its easier to read and flow better now (but is broken ;). The simpletests aren't working which is usual when I refactor something. I'll post the patch against head when I get everything working.

I committed this. In the process cleaned up the long _ldap_authentication_user_login_authenticate_validate(). Simpletests are working again. Turns out I broke them when I added () around the filter a couple of patches ago. I don't have sso setup, so couldn't test it.

- I changed $ldap_user = $ldap_server->user_lookup($userdn); to $ldap_server->user_lookup($name); Let me know if this is correct. If the lookup must use $userdn, it needs to derive $userdn. As it stands now, $userdn is only derived if the bind method for ldap is the user's login credentials.

- seems like the simpletests should be quite simple to write. instead of using the login function, we just set $_SERVER['REMOTE_USER'] and $_SERVER['REDIRECT_REMOTE_USER'] and test a page that requires authentication.

- I added error checking on the ldap authentication form such that if a server has user credential binding it will not allow SSO to be selected.

 public function validate() {
    $errors = array();

    $enabled_servers = ldap_servers_get_servers(NULL, 'enabled');
    if ($this->ssoEnabled) {
      foreach ($this->sids as $sid) {
        if ($enabled_servers[$sid]->bind_method == LDAP_SERVERS_BIND_METHOD_USER || $enabled_servers[$sid]->bind_method == LDAP_SERVERS_BIND_METHOD_ANON_USER) {
          $methods = array(
            LDAP_SERVERS_BIND_METHOD_USER => 'Bind with Users Credentials',
            LDAP_SERVERS_BIND_METHOD_ANON_USER => 'Anonymous Bind for search, then Bind with Users Credentials',
          );
          $tokens = array(
            '!edit' => l($enabled_servers[$sid]->name, LDAP_SERVERS_INDEX_BASE_PATH . '/edit/' . $sid),
            '%sid' => $sid,
            '%bind_method' => $methods[$enabled_servers[$sid]->bind_method],
          );

          $errors['ssoEnabled'] = t('Single Sign On is not valid with the server !edit (id=%sid) because that server configuration uses %bind_method.  Since the user\'s credentials are never available to this module with single sign on enabled, there is no way for the ldap module to bind to the ldap server with credentials.', $tokens);
        }
      }
    }
    return $errors;
  }

Rich, John,

I started to add a case in _ldap_authentication_user_login_sso function to handle our Pubcookie SSO. But then I just decided to try it first with the existing mod_auth_sspi setting. It works great. Auto user creation works and groups/roles look perfect. REMOTE_USER is REMOTE_USER, I guess.

In Drupal 6 we sync'd our entire LDAP to Drupal roles once an hour. Having this happen on user login will be much leaner and more up to date. I have often noticed with Pubcookie that it is difficult to really log out from an app during the 8-hour default lifetime of our Pubcookie cookie. And I want to make sure that folks don't query LDAP every time they change or reload a page. Is "logged in" set in a session?

It does not look like the logout cookie set in SSO session is effective in really logging out PubCookie users. There is a more specific function to logout out of Pubcookie that I will probably need to include. I am thinking that might be someting to add to the SSO section as part of individual configs for sspi, Pubcookie, CAS, et cetera.

The overall LDAP module is looking great! Thanks!

Jim

Thanks Jim. Its a fuzzy area to me, but until its clearer I think whatever patches to make pubcookie work are fine.

I feel its fuzzy because the only time ntlm, CAS, pubcookie etc have a relationship to ldap_authentication is when the CAS, pubcookie, etc source is LDAP. Otherwise there is no relationship. In the long run I think the work needs to go into the core user.module, but that may be some time.

Not sure off hand about your session/cookie questions.