26 February 2009, 7:15

Hello,

 I still cannot validate users in our Mahara site by means of the LDAP and IMAP authentication pluggins.  I use the XMLRPC pluggin to roam users from Moodle to Mahara (basic SSO configuration) and the Internal self-registration pluggin for creating new accounts in Mahara.

I asked the IT guy if, from the LDAP and IMAP servers side, they had to enable something in order to validate the connection against Mahara, and he said that everything was enabled.

I know that there is a bug reported for the IMAP pluggin. I tried the option "IMAP /NO TLS", as somebody suggested in another topic, but it didn't work for me.

I just want to ask if anybody is able to validate their students locally by using the LDAP pluggin. 

I have completed the last fields of the pluggin as follows:

LDAP field for First Name	givenName
LDAP field for Surname	sn
LDAP field for Email *	mail

Thank you very much for your advice

26 February 2009, 17:52

27 February 2009, 5:20

Thanks for answering, Nigel.

I have configured the LDAP pluggin in Mahara exactly in the same way that in Moodle.

Do you think that the problem may be then in the LDAP server ?

The LDAP server is set up in Novell. What do you recomend me to check in the server?

Regards

27 February 2009, 23:42

Well if the LDAP server works for Moodle with the same settings, I would be inclined to believe it was a problem in Mahara. Maybe you could do some debugging in the LDAP plugin to try and find out more information?

Use the log_debug function and check the apache error logs, and see if you can find out exactly where in the plugin's code things go wrong. And if you find something that is helpful that you could have used before, then tell us so we can make the plugin report it in future

If you don't find anything, then maybe it is a problem with your setup - maybe firewalling or something like that..

27 February 2009, 20:22

Hi Nigel,

I don't master the Mahara authentication internals (yet! ) but an ultra fast look at the code and the db seems to suggest that even if you enable multiple authentication plugins (actually instances of the plugins) for a given institution, only one is used for a given user.

I mean, when the user logs in for the first time, Mahara tries the all auth instances in the order they are configured and as soon as one of them is able to authenticate the user, it's assigned to her. And subsequent logins only use that particular auth instance. This is the same way Moodle works, by the way. Am I right?

And then, the XMLRPC plugin is a bit special in that it allows us to specify a 'parent' auth instance. When a user that has XMLRPC as her auth instance logs in directly (as opposed to roaming via MNET SSO), it uses that 'parent auth instance to authenticate the user 'locally' (via LDAP, IMAP, internally, etc, instead of talking to a IDP). So it's some sort of 'local fallback'. Am I right again?

Saludos. Iñaki.

27 February 2009, 23:49

Hi Iñaki - yes, you are right in both cases!

Users have one authinstance, this is stored in the usr table in the 'authinstance' column (the 'lastauthinstance' column will be removed soon, by the way). We've discussed internally about allowing users more than one authinstance, though it's a lot of work to do right.

And yes, the XMLRPC plugin provides a "parent". Really, "parent" is a bad name for it. It's a way to authenticate using Mahara's login form to get into the same user account.

01 March 2009, 12:07

Talking about allowing multiple authintances for a given user, I think it doesn't make much sense except for the XMLRPC auth plugin.

A given user only has one 'canonical' authentication source (be it LDAP, IMAP, OpenID, etc.). Whatever you use to identify that user (a username, a physical token, etc.), that id is only unique inside that
authentication source, and can (easily) be repeated across authentication sources for completely different users (e.g. the 'iarenaza' user in eps.mondragon.edu's LDAP server is a completely
different user than the 'iarenaza' in eteo.mondragon.edu's LDAP serve; they belong to two different people ). So providing multiple authinstances for a user doesn't make much sense.

The only exception to this scenario is when you start using roaming (i.e., XMLRPC),as the same user could roam from two (or more) different remote sites. In this particular case, tying the user authentication to a single XMLRPC authinstance won't let the user roam from the second (third, etc.) remote site.

I suspect that being able to have several 'parents' for the XMLRPC authinstances could do the trick. The parents would just need to have a flat structure (meaning we can't have a hierarchy of parents). This would make it easy to manage both the UI (present the admin with a
checkbox list of all the available authinstances and a label saying something like 'Users authenticated by this authority can alse be authenticated by these other authorities:') and the backend storage (a
simple additional m-n relationship table).

When a user logins via their assigned XMLRPC authinstance, we directly authenticate the user. When the user logins via a different XMLRC authinstance, we simply go through the list of parents asking them to authenticate the user. As soon as one of them does it, we accept the
login and finish. If none of them does, we reject the login.

Does that make sense?

Saludos. Iñaki.

01 March 2009, 18:28

Hi - sadly it's not quite as simple as that. The place where people need more than one authinstance is when they are members of more than one institution. In this case, we can't just say "you can use your ldap server for institution X but not for institution Y because you have a user in both. We need to allow it so that the user can log in using the LDAP username/password from X, and also (if exists) their different LDAP username/password from Y.

This brings into play the issue of globally unique identifiers for logging in, to which we were thinking that we could switch to using e-mail to log users in. Then we can do some fancy things. Like if a user signs in using the same e-mail address as an existing account, but from a different authinstance, we can make them prove they know the other way of logging in, then assign both authinstances to their same account.  There are details and complications around this area, but it is definitely workable.

The reason for this model is so that we can have students who can join and leave institutions, and thus gain and lose access via various methods over time, all to the same account.

02 March 2009, 5:51

Hello,

 Very interesting discussion. In principle, in our case, the LDAP pluggin is only used to create local users in Mahara who do not roam from Moodle (for different reasons). We have 6 academic schools in our college, and I have created an institution for each on them, with its corresponding LDAP pluggin. This is mainly for administration purposes: each institution has its own institution administrator who monitors students work, groups, etc.

When a user logs in first time in Mahara, the user can only belong to one academic school, at least  for that academic year, so he/she can only be validated against one institution (by the LDAP pluggin). Off course, if the student changes his academic school and joins another, we will have the same problem that Iñaki has pointed out.

However, reading your discussion, I have realised that I have enabled and configured the LDAP pluggin for each one of the six academic schools (pointing to exactly the same LDAP server). Mahara has no way then to find out which institution it should validate the student again.

 I am going to try using only one general institution-our college- and checking any possible firewall issues.

Regards

02 March 2009, 18:33

"However, reading your discussion, I have realised that I have enabled and configured the LDAP pluggin for each one of the six academic schools (pointing to exactly the same LDAP server). Mahara has no way then to find out which institution it should validate the student again."

Yeah, Mahara will try the users against the first one and put them in it. And that will be the end of it as far as the auth code is concerned

You could have all your users join 'No Institution', and then get them to join their institution in the system themselves.