Mahoodle://Integrating Mahara with Moodle //Integrating Mahara with Moodle ... work in the opposite direction, creating an opportunity for your users to SSO from Mahara to a Moodle server

Download Mahoodle://Integrating Mahara with Moodle //Integrating Mahara with Moodle ... work in the opposite direction, creating an opportunity for your users to SSO from Mahara to a Moodle server

Post on 12-Feb-2018




3 download

Embed Size (px)


  • Mahoodle://Integrating Mahara with MoodleHow many times each day do you find yourself loggingon to some service or other? As web applicationsgrow in popularity, users are obliged to juggleusername and password details for more websites,email programs and desktop applications, and theresno evidence that the trend is slowing.

    As administrators of interlinked web applications,we welcome any opportunity to make our systemseasier for people to access and use, and Single-Sign-On (or SSO) is one great way to achieve that. Simplyput, a user logs on to one application, and by clickingon specially crafted links that we provide there, istransparently authenticated to a second application,even though it may be running on another machine,in another room, on another continent.

    When SSO works well, it can dramatically improvethe sign-up experience for new users of yourapplication:

    No need to 'create an account'No need to find an unused usernameNo need to think up and remember yet anotherpasswordNo new URL to rememberNo need to log in to yet another applicationNo need to upload the same profile mugshot tothe new application

    If you could smooth the path for new users of yourapplication by removing all these obstacles, whatimpact do you think that might have on uptake?

    With the release of Mahara 0.8.1 and Moodle 1.9,you can now configure your Moodle so that any userwho logs in to Moodle can click on a link that willbring them to your Mahara site, and automaticallylog them on to their Mahara account. If they don'tyet have an account on Mahara, their user data willbe imported from Moodle, and used to populate theirMahara account. If they have a profile picture inMoodle, that will also be imported to their Maharaaccount.

    The user can then begin using the Mahara accountwith absolutely zero configuration required.

    Many Mahara users will want to keep using theirMahara account long after their formal relationshipwith your institution has ended, and your institution

    might well have an interest in keeping alive links toits alumni.

    With a few clicks of the mouse, you can configuremultiple points of entry for your Mahara users.

    If they want to sign on directly to Mahara, they cando so with a username and password. If they'vealready signed on to Moodle, they can click on a linkto SSO into Mahara. When their Moodle account isno longer active, they can no longer SSO, but theirMahara account remains available via directauthentication.

    Conversely, if you're the administrator of an existingMahara system you might want to configure SSO towork in the opposite direction, creating anopportunity for your users to SSO from Mahara to aMoodle server. If you choose this configuration foryour users, you can elect to have user recordsgenerated for them at the Moodle server on arrival.

    ~This document outlines three scenarios foradministrators of Moodle and Mahara systems, toassist in configuring their applications to interoperate.

    1://Basic NetworkingChapter one focuses on tasks that are commonto all three scenarios.

    2://SSO into MaharaChapter two will introduce what's likely to bethe most widely deployed option, of SSO fromMoodle to Mahara.

    3://Advanced SSO into MaharaIn chapter three, we'll look at some otheroptions for Mahara authentication, consideringthe confguration of multiple authenticationplugins, how they can be combined to createan authentication stack, and how we cancombine them to offer a single user multipleroutes into Mahara.

    4://SSO into MoodleIn the final chapter, we'll introduce SSO fromMahara to Moodle.

  • Mahoodle://Integrating Mahara with Moodle1://Basic NetworkingThe normal install procedures for Moodle and Maharaare already well documented. We'll assume that you'vealready installed both Mahara and Moodle, and thatthe sites are ready for an administrator to startconfiguring users and courses. If either site is alreadyin use, that's fine as well.

    Make sure that you are logged onto Moodle as anadministrator:

  • Mahoodle://Integrating Mahara with Moodle1://Basic Networking: MoodleFrom the Site Administration menu, click onNetworking >> Settings, and change the Networkingvalue to 'On'. Click 'Save Changes'.

    Before we do any more configuration on Moodle, weneed to enable networking on Mahara.

  • Mahoodle://Integrating Mahara with Moodle1://Basic Networking: MaharaMake sure that your Mahara site is set up, and thatyou're logged on as an Adminstrator:

    Click on Site Administration, and then on Networking:

  • Mahoodle://Integrating Mahara with Moodle1://Basic Networking: MaharaOn the networking page, your WWW Root should belisted. This is the canonical address at which yourMahara site can be accessed, and you'll need to enterthis address into your Moodle site later on.

    Beneath the WWW Root, is the Public encryptionkey. This is a file of seemingly random text, beginningwith the line '-----BEGIN CERTIFICATE-----'. Theexpiry date of the key is noted underneath. Maharawill automatically generate a new key when this oneexpires, and propagate the new key to your peers.

  • Mahoodle://Integrating Mahara with MoodleA Word On EncryptionWhen we think of a key for example the key for apadlock, we imagine that it can both lock and unlockthat padlock. Although we call these lines of text your'public key', this key is only used to 'lock' data notto unlock it. This key is part of a pair, each of whichis useless without the other. One locks the data, andthe other your private key unlocks it.

    So it's perfectly safe to publish this key withoutworrying about the security of your data. In fact we supply this key to other servers, and they use itto encrypt data that they want to send to us. Theyknow that the data it encrypts can only be decryptedby us, as we hold the corresponding private key.

  • Mahoodle://Integrating Mahara with Moodle1://Basic Networking: MaharaClick on the Enable Networking pulldown, and chooseYes'. The other pulldown menu 'Auto-register allhosts', is just fine set to 'No'. Click on 'Save changes'to continue.

  • Mahoodle://Integrating Mahara with Moodle1://Basic Networking: MaharaMahara acknowledges the choices that you havemade.

  • Mahoodle://Integrating Mahara with Moodle2://Enable SSO: MaharaClick on 'Admin home' to go back to the mainadministration menu, and on that page, in theManage Users' section, click on the link to'Institutions'.

    If you are certain that your Mahara site will only everserve one Moodle, click on Edit to update the detailsfor the default institution. Otherwise, click on 'Addinstitution', to create a new record for the institutionthat is hosting your Moodle. We'll detail the 'Addinstitution' option, although editing the defaultinstitution is almost identical.

  • Mahoodle://Integrating Mahara with Moodle2://Enable SSO: MaharaThe institution name can be any word made up ofonly letters. Spaces and numbers are not permittedin the institution name. The Institution display namecan include spaces and numbers. I've opted to givemy institution the name MahoodleMoodle and thedisplay name; Mahoodle Moodle.

    The authentication plugin can't be configured untilthe institution record has been created, so just ignorethat for the moment. The default values in the otherfields will be adequate to get started. Click on 'Submit'at the bottom of the page to save your settings. Thepage will reappear, and the authentication pluginmenu will be enabled.

  • Mahoodle://Integrating Mahara with Moodle2://Enable SSO: MaharaNote that the Institution name field is gone. It willbe hidden from both users and administrators fromthis point on.

    Choose xmlrpc from the Authentication pluginpulldown menu, and click on the plus-sign besidethat menu to add a new authentication method.

    A new window will open, displaying the configurationoptions for XMLRPC.

    This plugin can have a parent, but we will configureit without one; that means it will be the only meansfor users of the Moodle system to log on to theirlinked Mahara account.

  • Mahoodle://Integrating Mahara with MoodleConfiguring the XMLRPC pluginA new window will open with configuration optionsfor the xmlrpc plugin.

    The authority name will identify this authority toyou, the administrator. I've called this MahoodleXMLRPC, although I could just have called itXMLRPC because I already know that this authoritywill only authenticate users from the Mahoodleinstitution.

    The parent authority is 'None'. If we had alreadyconfigured an authority for this insitution, and thatauthority was itself canonical (i.e. does not requirea parent), then it would appear as an option in thisdropdown list.

    The next field WWW Root is absolutely crucialto get right, and most problems with Mahara &Moodle integration that we've experienced in testingare caused by errors in entering this value. In factit's very simple: the WWW Root must be exactly whatis specified in Moodle's config.php.

    Please take care not to enter a 'www' before the WWWroot hostname, if there is no www in your wwwrootfield. While it might be possible to access the Moodlesite at this URL, this will cause problems for you,and will likely prevent networking between the sitesfrom working.

    In short find out what is entered in the config.phpfile of your Moodle and enter exactly that.

    Choose the application that is being hosted at theremote site from the pulldown menu in our case,we want to choose Moodle and then enable somenetworked services by clicking on the checkboxesunderneath.

    By enabling 'They SSO in', you're permitting userswho log on at Moodle to enter your Mahara sitewithout having to log on again.

    By enabling 'Update user info on login', you're askingyour Mahara server to check that the user hasn'tchanged h