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.
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
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.
Saludos. Iñaki.
]]>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.
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..
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.
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
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 * |
Thank you very much for your advice
]]>