Development Information

Communication protocol Moodle-SAMUEL-INGRID

The developed Moodle plugin shows private information for each user so we must guarantee that the delivery of a model of a particular user is actually performed by that user. To do that, it has been established a communication protocol based on asymmetric cryptography.

At first, we make a request from the Moodle plugin to a SAMUEL web service, responsible for being an intermediary with INGRID, properly configuring the user model. As part of the request, certain parameters are provided, such as student ID, course ontology, the resource making the request or some other configuration settings. The request is made internally from the plugin itself, on PHP, so neither the URL of the web service nor its parameters are visible.

However, if anyone would know that values, he/she could get the private models of any user. To avoid this situation, the web service will request an adicional parameter: the signature. In this way, Moodle will sign each request with its own private key and the web service will verify that the signature corresponds with who claims to be before proceeding with the configuration of the model.

Thus, if a malicious user tries to view information of other users, he/she will not be able to do it because the private key used by Moodle remains unknown. Moreover, as each INGRID session is identified by a 32-digit hexadecimal value, which are being cleaned periodically, it is almost impossible to be able to access one of those models without knowing the ID.

On the other hand, INGRID allows grade proposals from both the teacher and the student. This feature is even more delicate because we can not allow a malicious user to impersonate someone proposing grades.

In a similar way to the above model querying, Moodle will create a signature to be added to the parameter list for each proposal and SAMUEL will verify, before registering the proposal, that the signature agrees with the provided data.

To enjoy a greater independence, proposal sendings in INGRID are not made to a fixed server or address, but it is established when configuring the user session. Therefore, it will be at that moment when the additional parameter will be added, which will encrypt both the identification of the user submitting the proposal and the type of proposal (student's or teacher's, represented by an additional learning resource).

Thus, SAMUEL, before storing the student's grade from the proposed resource, it will verify that the key matches with that values. To do that, it will use the resource's public key from where the grade is being proposed, in this case Moodle.

Get distributable plugin file

We can get a distributable file with all the necessary files to install the plugin in an existing Moodle installation.

Under the scripts folder, there is an ant build file for each resource supported by SAMUEL. This file is responsible of getting the respective keys and the appropiate configuration files for the resource.

So, if we want to get a plugin zip file for the Urano Moodle, we will use ant -f build-urano.xml or the default build.xml providing a parameter that indicates the resource: ant build.xml -Dresource=urano