13 August 2013, 0:57

I've copied this post across from the general Support forum.

Hi all,

We have Mahara and Moodle working succesfully together with SSO from Moodle -> Mahara.

We also have LDAP authentication for Mahara. Our users use LDAP for Moodle too, so the login is the same for both authentication types.

The problem I've noticed is this:Users who access Mahara for the first time via Moodle SSO have the authentication method in their account set to XMLRPC. If they then try to log in directly to Mahara, they are rejected. They can only login via Moodle, even though the login credentials for XMLRPC are identical to those for LDAP.

In my institution's list of authentication methods, I have set the order as follows:

• XMLRPC
• LDAP
• Internal

Swapping the order of the first two doesn't help.

I presumed that there was a fall-through process at work, so that if authentication method 1 failed, method 2 would be tried, etc. That doesn't seem to be the case, though the Internally authenticated accounts are still working OK.

So:

Can anyone else confirm this behaviour?

Is it a bug or a feature? ;)

Is there any way to enable fall-through authentication which I haven't spotted?

Thanks!

Mike

15 August 2013, 3:21

Hi Mike,

I've got the same problem. So far I've been asking staff and students if they use Mahara for the first time not to login directly but go through Moodle. Usually I ask them to do this during the induction. Then they are able to access it directly. But I couldn't find any way of sorting this out.

Marius

15 August 2013, 4:42

OK Marius, it's useful to know that it's not just me. I will investigate making a fix for this when I get back from leave in September.

Mike

15 August 2013, 16:59

Hi Mike,

I've been unclear on this one myself, so I went and re-examined the code to find out the answer. The short version is that Mahara only does "fall-through" for new user creation, but not for the login of existing users.

In other words, if the username you enter at the Mahara login form matches an existing Mahara user account, then it only checks against the auth method that user is set to use. If it doesn't match any existing Mahara account, then it checks all your auth methods in the order you've specified until it finds one that verifies their credentials, and it creates a new Mahara account and marks them for using that auth instance.

As for XMLRPC, though, if you set the "parent authority" of your XMLRPC auth instance to LDAP, that should solve the problem you're describing. (see http://manual.mahara.org/en/1.7/administration/institutions.html#index-10 ). What "parent authority" does, is it says that if a user is created by roaming across via XMLRPC, they should get the "parent authority" set as their login method for if they try to log in via the Mahara login form; and going the other way, if they are created via the Mahara login form using the parent authority, it will also set them up to be able to roam across via XMLRPC.

Back to the subject of "fall-through". If you're interested in implementing that, the magic happens in the function login_submit() in auth/lib.php (this is the Pieform submit callback function for the Mahara login form), which then calls LiveUser->login() in auth/user.php. If you look at those two functions together, you can see where login for an existing user (in LiveUser->login()) only checks one auth instance, while login for a not-yet-existing user (in login_submit()) checks every auth instance. Maybe put a similar loop into LiveUser->login()

This is a feature that people often assume Mahara has, and sometimes request, so it may be a good contribution to core. On the other hand, I suspect there may be some tricky corner cases to it which explain why it wasn't originally implemented this way.

Cheers,

Aaron

15 August 2013, 23:47

Hi Aaron,

That's really useful info, thanks. I'll follow this up after my break.

Best wishes,

Mike

12 September 2013, 23:13

Having looked at this, setting the parent authority fixes the issue we were having so I will leave everything else well alone ;)

Best wishes,

Mike