First, we deal with peer-to-peer networks where two Moodle servers are connected. For demonstration purposes, we have set up two sites (two peers); one is located at http://training.synergy-learning.com/login/index.php (Moodle) and the other at http://totara.synergy-learning.com/login/index.php (Totara). The two sites do not have to be in the same domain or the same organization. For example, two universities or two high schools might want to offer a collaborative course. They both have their own Moodle system in their own domain and they both control who gets access to which part of their site.
If your two sites are hosted in the same top-level domain and you are accessing both sites from the same web browser simultaneously, change the cookie prefix of one site (Server | Session handling) to avoid any conflicts.
Go to Networking | Manage peers and add a new remote host you want to connect to. We are currently working on http://training.synergy-learning.com/login/index.php and to establish a link to the remote server we have to enter http://totara.synergy-learning.com/login/index.php. Then perform the same step on the other host:
The pull-down menu offers an additional host type: mahara. Mahara is an open-source eportfolio system that can be integrated via the Moodle networking mechanism. We will cover this integration later in the chapter. For now, let's leave this setting at moodle.
Once the host has been added, enter the name of the Site, its Hostname, the level of security (SSL verification), and the Public key. (Optionally, select a Force theme that will be used when roaming.) Once the form has been saved, the expiry date (Valid until), the IP address, and Cert details of the remote server are displayed:
After you have saved the changes you will see three additional tabs at the top of the screen that provide details of the peer connection. You can always come back to this screen by selecting the respective host in Networking | Peers.
The SSO supported by Moodle avoids the need to log in when roaming to a remote site. The Services tab contains four areas. We will currently only focus on the last two, which deal with the SSO. The enrolment and portfolio services will be dealt with later on.
There are two SSO services that represent a two-way process and both services have to be set up on both Moodle sites by the respective administrators.
Peer services can be published and subscribed. It is important to note that publication and subscription are fully controlled by the local administrator. The administrator of the other site will never be able to modify any of those settings on your site.
Publish the identity provider service to allow your users to roam to the other site without having to re-login there. Subscribe to the identity provider service to allow authenticated users from the other site to access your site without having to re-login.
Publish the service provider service to allow authenticated users from the other site to access your site without having to re-login. Subscribe to the service provider service to allow your users to roam to the other site without having to re-login there.
Take the two collaborating universities we mentioned earlier. University A will publish the identity provider and University B will subscribe to it. Students from University A are now able to access restricted areas at University B's site without having to re-login.
|
Local Users |
Remote Users | |
|---|---|---|
|
Publish Identity Provider |
Allow roaming | |
|
Subscribe Service Provider |
Allow roaming | |
|
Subscribe Identity Provider |
Grant access | |
|
Publish Service Provider |
Grant access |
Each service has a reciprocal dependency on the other server, as shown in the table. For example, the subscribed SSO (Service Provider) on the local site requires the SSO (Service Provider) to be published on the other site. To allow roaming in both directions, all four boxes on both peers in your Moodle network have to be checked by the respective administrator.
When a user from one site roams to another site for the first time, a local user account is created and certain profile fields will be populated by fetching the data from the remote site. The default fields can be overridden by selecting any of the shown profile fields in the provided list. This setting exists for Fields to import (users who roam from another site to the local site) and Fields to export (vice versa):
The default fields can be changed in Networking | Profile fields. Fields that are included on your import list, but excluded on the remote site's export list, will be ignored.
Bear in mind that no password will be stored on the remote server. As the authentication mechanism will be set to MNet authentication, Moodle will check the credentials every time a user logs in. We will deal with authentication next.
To initiate roaming, you have to enable the Moodle network authentication plugin on both sites. Go to Plugins | Authentication | Manage authentication and enable the MNet authentication option. Every time a new user from a remote site logs in to this site, a user record is created automatically.
In the Settings screen, you will see a list of which host's users are allowed to roam in to your site and which local users are allowed to roam out. Only change the RPC negotiation timeout parameter if users experience sporadic timeout problems roaming from one site to another.
Only users assigned to a role with the moodle/site:mnetlogintoremote capability are allowed to roam to other sites. By default, this Roam to a remote Moodle capability is turned off and has to be allowed for each role. Go to Users | Permissions | Define roles, or revisit Chapter 6, Managing Permissions – Roles and Capabilities, for details on how to do this.
To turn on roaming for all users logged in to your site, allow the capability in the Authenticated user role. Unless all users are allowed to roam it is worth considering creating a separate roaming role. Alternatively, if you wish to grant (or deny) access to individual users from a remote host, go to Networking | SSO Access Control. You have to specify a user name, a remote host (the All hosts option is only relevant for the community hub mode, which is discussed later) and the access level (Allow or Deny).
The newly added user name does not have to exist in either Moodle site! In the list of users, the remote hub ID is displayed and not its name. This is the internal ID, similar to a user ID, group ID, or role ID.
Network users can also be assigned via CSV batch upload. We described the mechanics of the Users | Accounts | Upload users functionality in great detail in Chapter 5, User Management. The relevant field in the CVS file is called mnethostid.
Moodle provides a NETWORK SERVERS block, which has to be added to the front page. The block cannot be configured and is only displayed if the role of the logged-in user has the moodle/site:mnetlogintoremote capability mentioned previously set to Allow:
The block acts as a launch pad from which to access remote sites. Here, in addition to our Totara Demo peer, we have already set up a link to a Mahara instance, too. Once you click on the remote server, you will be re-directed to the selected site where you can enroll to remote courses. Your first peer-to-peer network is set up!
Moodle displays a different logged in message in the header. Instead of You are logged in as <user> (Logout), the message reads You are logged in as <user> from <peer> (Logout). This is similar to when you masquerade as another user. When you click on your name, you access the profile of the newly created user on the remote server, which cannot be changed. The Remote Moodle user - profile fetched from <peer> message is displayed.
Once roaming has been enabled and configured correctly, users will also see their remote course in the MY COURSES section and block, respectively (in our case, only one called Remote Course).
If you want to deny access for a remote user—for example, because of misconduct—go to Users | Accounts | Browse list of users and you will see that an additional column has been added to the list of users. Remote users cannot be edited locally, only the site they have logged in from is displayed. In the right-hand column, you select Deny access to revoke access to the site. To reverse the operation, select Allow access.
This last step is optional and is only required if you wish to grant an administrator in one Moodle system the permission to enroll local users in remote courses, and the other way round. This is useful if you run a shared course that is located on your server, but learners from the remote site should be participants. To minimize the administrative effort at your end, you grant the remote administrator the right to take on this task, which is limited to courses you have specified.
First of all, on the local site (that is, the one that grants the rights to the remote site), go to Plugins | Enrolments and enable the MNet remote enrolments plugin. This allows the local server to receive enrolments from its remote counterpart. In the Settings screen, you have the ability to change the default role (Student) for MNet enrolments.
Now, go to Networking | Peers, select the remote host, and click on the Services tab. Publish and subscribe to the Remote enrolment service. This grants remote administrators the right to enroll students on your site and allows local students to enroll in courses on the remote site, respectively. This step has to be repeated on the peer.
Both Moodle sites have now been configured to allow communication between the two servers and courses are set up to enroll remote students. Make sure you activate the MNet enrolment method inside your course (see Chapter 4, Course Management, for details).
When you go to Networking | Remote enrolments client, you will see a list of remote hosts where local users are enrolled. When you click on a host, courses offered for remote enrolment are displayed. You can then edit the enrolments in the same way you would manage users in a local course.
