Re: [Fwd: Re: Drupal SimpleSAMLphp integration & version 1.5]

32 views
Skip to first unread message

Snorre Løvås

unread,
Nov 19, 2009, 3:14:54 PM11/19/09
to Matt Pasiewicz, Anders Lund, drupalsi...@googlegroups.com
On 19.11.09 19.27, "Matt Pasiewicz" <autodida...@gmail.com> wrote:

> I've attached a pretty healthy refactor of the module and it appears to be
> working with 1.5X and uses all the latest and greatest API techniques from
> here ...
> http://rnd.feide.no/content/migration-modularized-saml-service-provider
>
> I'd be interested in thoughts/commentary.

I have committed the file to the trunk. I'll look into if I want to
reintroduce the block later when I upgrade some installations.


>
> Going forward, I'd also like to address this type of issue too...
> http://drupal.org/node/474714

I'm not sure what you are referring to here. I can have two user accounts
with the same e-mail address in my Drupal installations. As long as you
don't use the mail-attribute as the unique identifier in the ssp
configuration page in Drupal there shouldn't be a problem.

(I know some earlier versions of this module used mail as the only option,
and I think the Shib module still does...)

> Have you considered a project page on drupal.org<http://drupal.org>, even if
> you don't maintain it there, it would increase the visibility of the module.

Considered it, but never gotten around to it. :)
Probably should be done though. I'll look into it again.

Regards,
Snorre

--
Snorre Løvås
CTO
UNINETT ABC

Matt Pasiewicz

unread,
Nov 23, 2009, 4:16:00 PM11/23/09
to Snorre Løvås, Anders Lund, drupalsi...@googlegroups.com
> Going forward, I'd also like to address this type of issue too...
http://drupal.org/node/474714

For that, I was actually attempting to reference the following ...

Inasmuch as we already have accounts that should be accessible via federated login, I'd be interested in an interface that maps existing users.  I'm wondering if that shouldn't be done with a secondary module tho' ... and wondering if it might be interesting to add some hooks to the module using the invoke hook (simplesamlphp_auth_invoke) so that other modules could interject at various points in the simplesamlphp_auth module.


Sorry about missing _simplesamlphp_auth_get_default_name ... I've included my take on that below ... not sure about the pros and cons of the different approaches. I also updated simplesamlphp_auth_user to include a little extra error handling that I encountered during my testing.  



 /**
 * Implementation of hook_user().
 */
function simplesamlphp_auth_user($op, &$edit, &$account, $category = NULL) {
    global $as;
    global $saml_attributes; 
    
  if ($op == 'insert' && $category = 'account') {
    //if user registration has a valid session
    
    if ($as->isAuthenticated()) {
        //Get name from default attributes                                   
        
        try {
            _simplesaml_auth_debug('Registering user [' . $account->name . ']');
            $account->name = _simplesamlphp_auth_get_default_name($account->uid);
        } catch (Exception $e) {  
            $message = t('Username is missing.' . $e->getMessage());
            drupal_set_message($message, "error");
            watchdog('simplesamlphp', $message, WATCHDOG_CRITICAL);            
        }
        
        db_query("UPDATE {users} SET name = '%s' WHERE uid = %d", $account->name, $account->uid);
        _simplesaml_auth_debug('Updating username [' . $account->name . ']');
        
        //Get mail from default attribute
        try {
            $mail_address = _simplesamlphp_auth_get_mail();
        } catch (Exception $e)  {   
            $message = t('Email is missing.' . $e->getMessage()); 
            drupal_set_message($message, "error");
            watchdog('simplesamlphp', $message, WATCHDOG_CRITICAL);
        }
        
        if (!empty($mail_address)) {
            db_query("UPDATE {users} SET mail = '%s' WHERE uid = %d", $mail_address, $account->uid);
        }
        
        _simplesaml_auth_debug('Updating mail [' . $mail_address . ']');
    }
    
  }  elseif ($op == 'logout') {
      
      global $as; 
      global $saml_attributes; 

      if (!empty($saml_attributes)) {
          
          $config = SimpleSAML_Configuration::getInstance();
          $msg = 'with_slo';
          
          try {
            $slo = $config->getString('SingleLogoutService');
          } catch(Exception $e) {                          
              $msg = "no_slo";
          }
          $as->logout('/?msg=' . $msg);
          
      } 
     
  } else if ($op == "delete") {
    db_query("DELETE FROM {authmap} WHERE uid = %d AND authname = '%s' AND module = 'simplesamlphp_auth'", $account->uid, $account->name);
  }
}





function _simplesamlphp_auth_get_default_name($account) {
    global $as;
    global $saml_attributes;
    $default_name = '';
 
    /* Check if valid local session exists.. */
    if ($as->isAuthenticated()) {
        $attributes = $saml_attributes;
        switch (variable_get('simplesamlphp_auth_user_name', 'eduPersonPrincipalName')) {
            case "eduPersonPrincipalName":
              if (!isset($attributes['eduPersonPrincipalName'])) {
                throw new Exception(t('eduPersonPrincipalName was not set for your user.'));
              }
                $default_name = $attributes['eduPersonPrincipalName'][0];
                break;
            case "smartname-fullname-eduPersonPrincipalName":
              if (!isset($attributes['smartname-fullname'])) {
                throw new Exception(t('smartname-fullname was not set for your user.'));
              }
              if (!isset($attributes['eduPersonPrincipalName'])) {
                throw new Exception(t('eduPersonPrincipalName was not set for your user.'));
              }
              $default_name = $attributes['smartname-fullname'][0] . " [" . $attributes['eduPersonPrincipalName'][0]. "]";
              break;
            case "smartname-fullname-drupaluid":
              if (!isset($attributes['smartname-fullname'])) {
                throw new Exception(t('smartname-fullname was not set for your user.'));
              }
              $default_name = $attributes['smartname-fullname'][0]. " [" . $account->uid . "]";
              break;
            case "smartname-fullname":
              if (!isset($attributes['smartname-fullname'])) {
                throw new Exception(t('smartname-fullname was not set for your user.'));
              }
              $default_name = $attributes['smartname-fullname'][0];
              break;
            default:
              throw new Exception(t('error in simplesamlphp_auth.module: no valid name attribute set'));
          }
    
    }
    return $default_name;
}

Snorre Løvås

unread,
Dec 1, 2009, 12:06:21 PM12/1/09
to drupalsi...@googlegroups.com, Snorre Løvås, Anders Lund
On Mon, Nov 23, 2009 at 22:16, Matt Pasiewicz
<autodida...@gmail.com> wrote:
>
>> Going forward, I'd also like to address this type of issue too...
>> http://drupal.org/node/474714
> For that, I was actually attempting to reference the following ...
> http://drupal.org/node/508410

Ah... That makes much more sense :)

> Inasmuch as we already have accounts that should be accessible via federated
> login, I'd be interested in an interface that maps existing users.  I'm
> wondering if that shouldn't be done with a secondary module tho'

One way to go is to let the users do it themselves - first log into
local account, then do a federated/external login and map the
federated id to the local account. This should really be done in a
controlled manner so the user don't accidentally map users, and you
probably want to be able to unmap users too. Maybe as an extension to
the user-page.

Another way could be to give the administrators a form where they can
map and unmap local accounts to external accounts.

Both could be done within the module, but it's a generic issue with
all external authentication sources, SimpleSAMLphp, OpenID, whatnot,
and a "Authmap administration module" would have been great. In
principle it could be a few forms and heavy use of user_get_authmap()
and user_set_authmap(). Don't know if it is best practice to use those
to methods directly though...


Regards,
Snorre
Reply all
Reply to author
Forward
0 new messages