Forums | Mahara Community

Open Discussion /
How to sign in Mahara?


anonymous profile picture
Account deleted
Posts: 338

11 December 2008, 6:45

Hello,

 We are going to have a strategic meeting about our Mahara eporfolio platform this evening and I would like to canvass the opinion of the international community about the following issue:

  • The way that educational institutions tend to set up Mahara is by integrating it with Moodle 1.9. Users roam from a Moodle site to a Mahara site as the MNET (Moodle) and xmlrpc (Mahara) pluggins are working fine.


The reasons given for this is to avoid additional "sign ons". The idea is to sign on in Moodle by using Shibboleth (in the UK this authentication method is more extended than OpenID), LDAP or IMAP, and then just roam from Moodle to Mahara.

 However, I believe that there is a risk of “Moodle-dependency” in that case: if, for some reason, in future, the organization decides to migrate to another Course Management Software, what happens with the users accounts already created in the mahara_users table as roamed users from Moodle? Did users have to create a new account in Mahara since they don’t roam from Moodle anymore?

I can also see a technical risk here: 

  • If the Moodle site collapsed foor some reason or is hacked (the vulnerability risks of Moodle 1.8.3, for instance, are well documented, and Moodle 1.9 has not solved all of them) this also stops users from logging to the Mahara site.

  •  

  • How would it be the performance of the xmlrpc code whrn both sites-Moodle and Mahara- are set up in busy servers with a high numbe of simultaneous connections?



Therefore I wonder:

 

  • What is the added valued of roaming from Moodle to Mahara?

  •  Would it be better to keep the eportfolio platforms and  the VLE platforms separate?

  • If  a learner is not enrolled in Moodle courses anymore, does it automatically mean that he cannot access his eportfolio ? (Remember the conception of eportfolio as “a personal online space that belong to learner as well as to the institution)


If what we just want is  a "sign-on policy", then why don't we develop authentication pluggins for Shibboleth and OpenID  in Mahara? … I imagine that these pluggins may be under development already.

For me it would be very insightful if  those who are already running Mahara production sites could share your experiences  with me to support my case.

 Regards

Howard Miller's profile picture
Posts: 191

11 December 2008, 7:48

Hi,

 

Well there isn't a "risk" of Moodle dependency, there *is* Moodle dependency - almost by definition. If you want to have single sign on using the same information as Moodle holds then this is a price you pay. It does indeed create additional complexity and possible points of failure but you have to balance that against the benefits to your users.

 If you can get the horror that is Shibboleth to work then none of this should be any problem at all Cool

 If you do decide to remove Moodle from the equation, the user accounts remain within Mahara. You would need to do some fiddling to make them usable - at a minimum the user needs to set a password in Mahara but if you do it right Mahara will send out a sensible message and manage all that for you. 

On the xmlrpc load question, my feeling is that the amount of traffic should be fairly small as it only occurs during authentication. I have certainly see no issues. 

anonymous profile picture
Account deleted
Posts: 338

11 December 2008, 10:37

Thanks for reply.

Where can I found what it has been done until now about Shibboleth and OpenID (or even Facebook connect) in Mahara?

The only information I can found is an old post mentioning OpenID 

anonymous profile picture
Account deleted
Posts: 1643

11 December 2008, 18:23

Hi,

There is very little risk of a Moodle dependency. To see why, consider this: Mahara treats how you authenticate yourself to get into a Mahara account differently to the account itself.

This is done through "authinstances" - which can be assigned to institutions. When you set up Moodle authentication, you set up an XMLRPC authinstance. Then when users roam, their newly created accounts are linked to that authinstance.

Even user accounts that just register on the site and log in through the login box are assigned to an 'internal' authinstance. All authinstance code can be seen in the auth/ subdirectory.

Therefore, should you move from Moodle to another LMS, there is nothing to stop you assigning those accounts to a new authinstance - even an XMLRPC one for the new LMS. And as Howard points out, there is already some support within Mahara to allow users access to their accounts if they can't get to their LMS - you can switch them to a different authinstance and Mahara will send them an e-mail about it.

Regarding your technical risks:

  • Yes, if Moodle is hacked, the Mahara users won't be able to get in through moodle. This is to be expected. A lot of people rig the authentication up so that users can get into Mahara both through moodle and through, for example, an LDAP server. Howard Miller and the Glasgow team have been using this extensively.
  • Regarding performance - there's only one XMLRPC request sent when users roam in, and one when they click 'sign out' (this may trigger a few more but not in a Mahara-as-a-hub scenario). These requests are just like any other HTTP request. There's no real performance bother. It's not like a request is sent for every page you load on either site Smile


Given the above, the added value is that you allow your users to seamlessly roam between some other system (not just moodle! anything that implements MNET can do this, for example there is some code to make drupal do this too) and Mahara. This is a great usability boon. The MNET system can also be used to share information between any other system and Mahara too, which can make the integration tighter if you need.

As you can see from the above, the LMS and eportfolio are separate. They're only transiently tied together for the purposes of authentication, a bond that can easily be broken if required. I would be far more worried about other eportfolio systems that implement themselves inside Moodle, to be honest.

PS: I would like to think that the concept of an eportfolio was a "personal online space that belongs to the learner" - the institution doesn't really have any ownership at all of the users' portfolios, even if they are hosting it and performing some assessment through it Smile. Just my 2c.

Regarding authentication plugins (shibboleth, openID) - they're not under development by the core team. We're too busy with Mahara 1.1! There is the pluggable authentication API of course, for anyone who's keen to develop it, and we'd certainly be interested in taking the plugins back upstream.

And one last note: We (the Mahara devs, and some of the Moodle people here at catalyst) have talked about the potential to allow accounts to have multiple authinstances assigned to them - which would be great for when a user is enrolled at two different institutions who both share the same Mahara hub. They could then get in through either institution to their account, and of course continue to access the system if one of the institutions kicks them out.

Hope that helps! 

anonymous profile picture
Account deleted
Posts: 338

12 December 2008, 5:59

Thanks for your reply, Nigel.

 I totally agree with the concept of  Eportfolio as online space that belongs to the learners. However, the reality is that many institutions in the UK conceive eportfolios as "e-assessment"...and that is. Indeed, when you try to explain how Mahara works to lecturers, they find difficult to understand that the teacher doesn't have any control over the student's view, like in Moodle.

 I did my postgraduate dissertation in education at the University of Plymouth based on the vision of education  by  J. Krishnamurti and Ghandi (There is a free ebook of "Education as a service" in the Guttenberg Project: http://www.gutenberg.org/etext/11345£). Both would have definitively agreed with the conception of eportofolio as a personal journey to wisdom and awareness.

 Regards

 

5 results