Moodle
  1. Moodle
  2. MDL-40905

META: Evolve MNet into a standards-based system

    Details

    • Rank:
      51809

      Description

      MNet is a mess. It's a proprietary protocol with many known bugs, and no-one want to work on it. For some time we've talked about replacing it with standard protocols.

      This needs to be done in concert with Mahara to make sure we don't break connections.

      This issue is the starting point for that process.

      My rough conception of the plan is as follows:

      1) Identity SSO: Replace remote login with a full-featured oauth/oauth2 implementation. This will allow any Moodle site to designate any other Moodle site for authentication, as well as allowing login via Google/Twitter/Facebook etc. Mahara can authenticate using Moodle or vice versa. The user should have full knowledge and control over profile data being shared between systems.

      2) Enrolment: Replace remote course enrolment by LTI at a course level. This will allow your courses on site B/C/D to appear in your site A, probably inside a special "Remote courses" category. Note this is not limited to Moodle courses, although of course we can make discovery of these more automatic. LTI can also pass the total course grade back, so we should support the storage and display of this too.

      3) Portfolio services: One option here is for Mahara to expose files as a WebDAV service, and for Moodle to be able to push things to any WebDAV server via the Portfolio API.

      And that should cover it.

      Let's discuss the plan here, build a spec and get started ASAP.

        Issues in Epic

        There are no issues in this epic.

          Activity

          Hide
          Aaron Wells added a comment -

          From Mahara's side, how we currently use Mnet. In order of frequency:

          1. Using Moodle as an identity provider for user authentication and provisioning.

          2. The "Mahara" assignment subtype plugin for Moodle (see https://wiki.mahara.org/index.php/System_Administrator%27s_Guide/Moodle//Mahara_Integration/View_Submission ). This allows students to submit a link to a webpage created on their Mahara account, as their assignment submission. It uses Mnet and Mnet-based web services for the following:

          • Fetching the list of Pages in the student's Mahara account
          • Creating an access token to allow the teacher to view the submitted Mahara Page
          • Locking the submitted Mahara Page so it can't be edited, then unlocking it after it has been graded.
          • We've also been discussing sending an archived copy of the page back over to Moodle as an exported HTML or Leap2A file
          • Optionally communicating outcomes (which I believe are a bit like rubrics) back to Mahara after the Page is graded in Moodle

          3. The "Mahara" portfolio type plugin for Moodle. I haven't had much of an opportunity to look at this, but from what I understand, a user's content in Moodle gets exported into a file, the file is transferred over to Mahara, and Mahara imports the contents of the file back into Mahara Artefacts.

          4. We've been kicking around the idea of a Mahara repository plugin in Moodle, but have continually pushed it back waiting for Mnet replacement.

          I'll check with my colleague Kristina to see if I've missed anything. As far as I can tell, OAuth sounds good as an authentication replacement. I'll have to look into the options for web services. I believe currently our only implemented web services API in core is XMLRPC via MNet, but there is a web services plugin written by Piers Harding in mahara-contrib: https://gitorious.org/mahara-contrib/auth-webservice/

          Show
          Aaron Wells added a comment - From Mahara's side, how we currently use Mnet. In order of frequency: 1. Using Moodle as an identity provider for user authentication and provisioning. 2. The "Mahara" assignment subtype plugin for Moodle (see https://wiki.mahara.org/index.php/System_Administrator%27s_Guide/Moodle//Mahara_Integration/View_Submission ). This allows students to submit a link to a webpage created on their Mahara account, as their assignment submission. It uses Mnet and Mnet-based web services for the following: Fetching the list of Pages in the student's Mahara account Creating an access token to allow the teacher to view the submitted Mahara Page Locking the submitted Mahara Page so it can't be edited, then unlocking it after it has been graded. We've also been discussing sending an archived copy of the page back over to Moodle as an exported HTML or Leap2A file Optionally communicating outcomes (which I believe are a bit like rubrics) back to Mahara after the Page is graded in Moodle 3. The "Mahara" portfolio type plugin for Moodle. I haven't had much of an opportunity to look at this, but from what I understand, a user's content in Moodle gets exported into a file, the file is transferred over to Mahara, and Mahara imports the contents of the file back into Mahara Artefacts. 4. We've been kicking around the idea of a Mahara repository plugin in Moodle, but have continually pushed it back waiting for Mnet replacement. I'll check with my colleague Kristina to see if I've missed anything. As far as I can tell, OAuth sounds good as an authentication replacement. I'll have to look into the options for web services. I believe currently our only implemented web services API in core is XMLRPC via MNet, but there is a web services plugin written by Piers Harding in mahara-contrib: https://gitorious.org/mahara-contrib/auth-webservice/
          Hide
          Lilian HUGUES added a comment -

          If I may add a comment.
          IMHO, we also need to think Mahara as entry point as social network.
          It's in that way I manage my Mahoodle : mahara as the Master and Moodle as the slave. The issue is that once you are on moodle you can not send artefact to mahara or pull artefact from mahara because you are view as remote user (with limitations)

          A real bi-direction communication is needed.

          Many thanks for developpers of both platforms for your wonderfull job

          Show
          Lilian HUGUES added a comment - If I may add a comment. IMHO, we also need to think Mahara as entry point as social network. It's in that way I manage my Mahoodle : mahara as the Master and Moodle as the slave. The issue is that once you are on moodle you can not send artefact to mahara or pull artefact from mahara because you are view as remote user (with limitations) A real bi-direction communication is needed. Many thanks for developpers of both platforms for your wonderfull job
          Hide
          Geoffrey Rowland added a comment -

          Just wanted to second Lilian's comment about communication between Moodle and Mahara being fully bi-directional. I have stuck with the 'traditional' Moodle (master) to Mahara (slave) authentication but see logic and potential going the other way.

          Show
          Geoffrey Rowland added a comment - Just wanted to second Lilian's comment about communication between Moodle and Mahara being fully bi-directional. I have stuck with the 'traditional' Moodle (master) to Mahara (slave) authentication but see logic and potential going the other way.
          Hide
          Jordi Pujol-Ahulló added a comment -

          To add some other context in order to show the need of a fluid SSO without using the archaic MNET, I will show you our deployment in our University, Universitat Rovira i Virgili, Tarragona, Catalonia.

          We have a master Moodle instance, with a full, automatic syncronization of users (creation and fields updating), as well as course and categories generation.

          We have another Moodle instance, slave from our main master Moodle instance. The main reason this instance is slave, is because the use is not so big, with few users (some from the master Moodle instance, other users external to the University, added manually), but with a necessity of flowing in a SSO manner between instances (once you have logged in to the master instance). So, the infrastructure is not so important as for the master instance, so we do not duplicate efforts maintaining synced users on both instances. However, the user of MNET put us in a mesh to manage users successfully among both instances.

          We have a Mahara instance, slave from our master Moodle instance. Again, you need to log in the master Moodle instance to get into Mahara.

          The key points for us is:

          • Easy-to-use SSO, even though we should need that any user start logging in the master Moodle instance.
          • Automatic creation of users among Moodle instances once a user logs in the master Moodle instance. This will help the site administrators of the slave site (staff different from the master Moodle instance) to assign users as teachers and students into courses, finding the users into its own Moodle instance (without wainting for a MNET or remote log in).

          Hope this helps.
          Jordi

          Show
          Jordi Pujol-Ahulló added a comment - To add some other context in order to show the need of a fluid SSO without using the archaic MNET, I will show you our deployment in our University, Universitat Rovira i Virgili, Tarragona, Catalonia. We have a master Moodle instance, with a full, automatic syncronization of users (creation and fields updating), as well as course and categories generation. We have another Moodle instance, slave from our main master Moodle instance. The main reason this instance is slave, is because the use is not so big, with few users (some from the master Moodle instance, other users external to the University, added manually), but with a necessity of flowing in a SSO manner between instances (once you have logged in to the master instance). So, the infrastructure is not so important as for the master instance, so we do not duplicate efforts maintaining synced users on both instances. However, the user of MNET put us in a mesh to manage users successfully among both instances. We have a Mahara instance, slave from our master Moodle instance. Again, you need to log in the master Moodle instance to get into Mahara. The key points for us is: Easy-to-use SSO, even though we should need that any user start logging in the master Moodle instance. Automatic creation of users among Moodle instances once a user logs in the master Moodle instance. This will help the site administrators of the slave site (staff different from the master Moodle instance) to assign users as teachers and students into courses, finding the users into its own Moodle instance (without wainting for a MNET or remote log in). Hope this helps. Jordi
          Hide
          Dan Marsden added a comment -

          Jordi - I don't think Moodle should be the "source" of the SSO in those cases and I'm not 100% certain that we should replace the SSO component of Mnet (but I do like the idea of having full oauth support)

          When providing SSO to multiple systems you're better to implement something like SAML - where an separate system is responsible for authentication and allows SSO with multiple applications. That way it doesn't matter which system you hit first.

          Show
          Dan Marsden added a comment - Jordi - I don't think Moodle should be the "source" of the SSO in those cases and I'm not 100% certain that we should replace the SSO component of Mnet (but I do like the idea of having full oauth support) When providing SSO to multiple systems you're better to implement something like SAML - where an separate system is responsible for authentication and allows SSO with multiple applications. That way it doesn't matter which system you hit first.
          Hide
          Hubert Chathi added a comment -

          I agree with Dan M. and Lilian. I think that we should have more flexibility in linking Moodle and Mahara accounts so that we could have either end as the identity provider, or use a completely different service as the identity provider.

          Regarding OAuth and SSO, as far as I can tell, OAuth isn't an SSO protocol in and of itself, because you need to define a function to call, there's no standardized discovery protocol, etc. so even though various services use OAuth for SSO, they may not be completely compatible (that is, every service may need some custom code). Perhaps someone more familiar with OAuth (paging Dan P.) could clarify.

          My gut feeling is that we could split MNet into a whole bunch of desired functionality, and that each functionality could be handled separately, instead of trying to handle everything with a single protocol. For example, we already have various SSO solutions to replace MNet, and if we can get the other parts of MNet to work with the other SSO solutions, then we don't need to do much there (unless someone wants to write an OAuth identity provider, or stuff OpenID into core). Portfolio could be handled by a new standard OAuth function call (or WebDAV as Martin mentioned, though I don't see any reason, aside from manpower, why both options shouldn't exist), and could even be independent of any SSO mechanism. For example, if my school runs a Mahara instance, I could push my work there. But what if I want to plop my work into some other portfolio hosted somewhere else (or even if I ran my own Mahara instance)? I think it would be nice if I could just type a URL into Moodle, and have it make an OAuth call to the other site to push my work to.

          Show
          Hubert Chathi added a comment - I agree with Dan M. and Lilian. I think that we should have more flexibility in linking Moodle and Mahara accounts so that we could have either end as the identity provider, or use a completely different service as the identity provider. Regarding OAuth and SSO, as far as I can tell, OAuth isn't an SSO protocol in and of itself, because you need to define a function to call, there's no standardized discovery protocol, etc. so even though various services use OAuth for SSO, they may not be completely compatible (that is, every service may need some custom code). Perhaps someone more familiar with OAuth (paging Dan P.) could clarify. My gut feeling is that we could split MNet into a whole bunch of desired functionality, and that each functionality could be handled separately, instead of trying to handle everything with a single protocol. For example, we already have various SSO solutions to replace MNet, and if we can get the other parts of MNet to work with the other SSO solutions, then we don't need to do much there (unless someone wants to write an OAuth identity provider, or stuff OpenID into core). Portfolio could be handled by a new standard OAuth function call (or WebDAV as Martin mentioned, though I don't see any reason, aside from manpower, why both options shouldn't exist), and could even be independent of any SSO mechanism. For example, if my school runs a Mahara instance, I could push my work there. But what if I want to plop my work into some other portfolio hosted somewhere else (or even if I ran my own Mahara instance)? I think it would be nice if I could just type a URL into Moodle, and have it make an OAuth call to the other site to push my work to.
          Hide
          Wendell Jones added a comment -

          If I could make a humble request...

          Could we please not refer to this process as "removing" MNet? I understand how developers who have had to live with the current MNet implementation would like to kill it, but as far as I have heard, no one is even suggesting losing any of the functionality of MNet. Unfortunately, I often have people reluctant to consider MNet because they have seen something saying that MNet is being "removed" or "discontinued". I would even suggest that the replacement be referred to as MNet2, indicating that it is a new, improved implementation which, although not necessarily compatible, carries on and adds to the existing functionality. Just MHO, of course.

          Wendell

          Show
          Wendell Jones added a comment - If I could make a humble request... Could we please not refer to this process as "removing" MNet? I understand how developers who have had to live with the current MNet implementation would like to kill it, but as far as I have heard, no one is even suggesting losing any of the functionality of MNet. Unfortunately, I often have people reluctant to consider MNet because they have seen something saying that MNet is being "removed" or "discontinued". I would even suggest that the replacement be referred to as MNet2, indicating that it is a new, improved implementation which, although not necessarily compatible, carries on and adds to the existing functionality. Just MHO, of course. Wendell
          Hide
          Martin Dougiamas added a comment -

          Thanks Wendell, how's that now?

          Show
          Martin Dougiamas added a comment - Thanks Wendell, how's that now?
          Hide
          Wendell Jones added a comment -

          Well, I think that is excellent! Thanks Martin.

          So, is there any activity on this that isn't showing up here?

          Wendell

          Show
          Wendell Jones added a comment - Well, I think that is excellent! Thanks Martin. So, is there any activity on this that isn't showing up here? Wendell
          Hide
          Derek Chirnside added a comment -

          Just curious. As of today, where is this up to? Is there a current version of any thinking/planning? If you were thinking of networking several Moodles this year in some way, what is an option?

          -Derek

          Show
          Derek Chirnside added a comment - Just curious. As of today, where is this up to? Is there a current version of any thinking/planning? If you were thinking of networking several Moodles this year in some way, what is an option? -Derek
          Hide
          David Mudrak added a comment -

          Honestly, this is in limbo and it would not be fair to pretend the opposite. To let the MNet evolve from the ugly caterpillar to the beautiful butterfly, we would need somebody to dive really deep into the subject and spend with it some time. This is not a weekend project. To map the situation, gather alternatives and implement a reliable solution would take at least three man-months. Really. And I think it's still pretty naive estimation if we want to have it done properly (so it actually serves well, not just "seems to work").

          AFAIK the rough plan is still the same. 1) Convert all useful MNet RPCs to in-built web services, 2) ship Moodle with native WS client(s) so that it can connect to other sites in the MNet, 3) implement a standard SSO solution in Moodle (SAML via SimpleSAMLphp has been considered seriously) and 4) implement a new communication protocol for our WS framework that would provide the SSL security and digital signature layer present in the MNet protocol (unless we decide that it's the duty of site admins to actually run their sites over HTTPS).

          Show
          David Mudrak added a comment - Honestly, this is in limbo and it would not be fair to pretend the opposite. To let the MNet evolve from the ugly caterpillar to the beautiful butterfly, we would need somebody to dive really deep into the subject and spend with it some time. This is not a weekend project. To map the situation, gather alternatives and implement a reliable solution would take at least three man-months. Really. And I think it's still pretty naive estimation if we want to have it done properly (so it actually serves well, not just "seems to work"). AFAIK the rough plan is still the same. 1) Convert all useful MNet RPCs to in-built web services, 2) ship Moodle with native WS client(s) so that it can connect to other sites in the MNet, 3) implement a standard SSO solution in Moodle (SAML via SimpleSAMLphp has been considered seriously) and 4) implement a new communication protocol for our WS framework that would provide the SSL security and digital signature layer present in the MNet protocol (unless we decide that it's the duty of site admins to actually run their sites over HTTPS).

            People

            • Votes:
              14 Vote for this issue
              Watchers:
              39 Start watching this issue

              Dates

              • Created:
                Updated: