Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-40905

META: Evolve MNet into a standards-based system

    Details

      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.

      Forum discussion: https://moodle.org/mod/forum/discuss.php?d=175158
      Spec in progress: https://docs.moodle.org/dev/MNet_Roadmap

        Gliffy Diagrams

          Issue Links

            Issues in Epic

            There are no issues in this epic.

              Activity

              Hide
              aaronw@catalyst.net.nz 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
              aaronw@catalyst.net.nz 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
              blibuk 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
              blibuk 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
              geoffr 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
              geoffr 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
              jpahullo 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
              jpahullo 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
              danmarsden 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
              danmarsden 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
              hchathi 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
              hchathi 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
              gwjones 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
              gwjones 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
              dougiamas Martin Dougiamas added a comment -

              Thanks Wendell, how's that now?

              Show
              dougiamas Martin Dougiamas added a comment - Thanks Wendell, how's that now?
              Hide
              gwjones 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
              gwjones 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
              derekcx 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
              derekcx 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
              mudrd8mz 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
              mudrd8mz 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).
              Hide
              anitsirk Kristina Hoeppner added a comment -

              We'd like to know from users / developers etc. what they would like to be able to achieve from a future authentication between Moodles and Moodle and Mahara(s). Please fill in the survey at https://docs.google.com/forms/d/1vyECf8s8lyEX6YJuf9SGe7sUN5flaROcfBF7mPxY9fc/viewform

              Deadline: 20 June 2014

              Thank you
              Kristina

              Show
              anitsirk Kristina Hoeppner added a comment - We'd like to know from users / developers etc. what they would like to be able to achieve from a future authentication between Moodles and Moodle and Mahara(s). Please fill in the survey at https://docs.google.com/forms/d/1vyECf8s8lyEX6YJuf9SGe7sUN5flaROcfBF7mPxY9fc/viewform Deadline: 20 June 2014 Thank you Kristina
              Hide
              dougiamas Martin Dougiamas added a comment -

              I was only just made aware of this survey. Where are the results please?

              Show
              dougiamas Martin Dougiamas added a comment - I was only just made aware of this survey. Where are the results please?
              Hide
              vf Valery Fremaux added a comment -

              On martin's demand, here is an experience return of using extensively on MNet and starting balancing with standard WS.

              I drove from 2008 several projects of "global LMS urbanisation" highly based on Mnet strategies do divide LMS ara into administative independant, but yet consistant "zones". This was concommitant with the development of VMoodle virtualisation, leading to one single install governing all moodles in an array, largely Mnet bound. Pairformance is a 31 moodles array, using a Full Mnet topology (all node is bound to every 30 other nodes), The Académie of Strasbourg project proposes 70 singular school moodles in an array start connected to one central common unit. Paris Descartes University was installed with 13 VMoodle nodes in an enhanced Mnet auth integration so called MultiMnet, to resolve the "unique identity at every outside door (even unregistered)". All these projects could lead me to very extensively measure strengths and weaknesses of Mnet, from a functional and exploitation point of view :

              • Weaknesses :
                1. Key obsolescence breaking Mnet based web services / Users explicit romaing repar keys, Underlying cross platforms web services do not. We added in VMoodle a special automated key renewal (inside trust network), that works strongly since years without special care. Indeed, in case of severe perturbation (DNS break) during key renewal, this can mess largely the array, and ask me to use my massive weapon (global key renewal script)
                2. Crossing information builds too many and hard to work with dependant information using remote enrolment. We actually dicard any use of remote enrolment, prefering implement a "user propagation and ask remote for enrolement" strategy, linking data much less than Mnet enrolment.
                3. Multijumping from A to B, A to C and A to B to C : creating a mess of identities in C (a from A and a from B). This is easy to adress and has been resolved mostly in all our installs.
                4. In some topologies (star topology), unicity of user is not guaranteed (say start moodle is S, a in A and a in B leads to 2 identities in S : a from A and a from B – we have this for public education teachers having assignation in two schools). This is under resolution.
                5. Mnet has no intrinsic user identity transport when exchanging Mnet requests, the question of the remote capabilities of the calling user of the request needs to be developped in each function. My implementation of this is a bit weak and does not have standard fallbacks to drive user with a comprehensible fedback (actually makes big Moodle error, logical, but not user friendly).

              Apart of those real use cases and tricky situation, and apart some roughness of the Mnet code, regarding to much "higher OO conceptual implementations, Mnet as conceptual advantages in terms of service management. So let us make some advocacy in favour of Mnet :

              • Strenghs :

              1. Clearness of the platform cross service agreement : The process of cross exchanging Mnet identity makes the environment network topology predictable and drawable.
              2. Service organisation : While WS also present a service level definition, this one is much less formal and clear to map and monitor. The service definition in Mnet is a real good tool to design complex multi-node topologies, and formalize network service organisation. I fear we loose that easy to view architecture in a global WS system that will not differentiate any more what are internal services (structural) and what are external services (bridges, connectors, extrinsic integration). Using actual WS service definition would lead to a big work of the administrator to build and assemble webservices on each node, while Mnet just asks to enable/disable them to build the service topology).
              3. The excellent "remote view of service states" when binding symmetric services.
              4. Strongly dividing load on each plaform : a 50.000 students organisation falls to 10 units of 5000 students + some shared accounts that are not o many.
              5. Allows distinct decisions of adminiistration and administration delegation to school departments in an autonomous way. Say a Litterature and Humanities dpt has not same needs and organisation than a Science dpt.

              I noticed that initial use of mnet was thought in an open thinking of crossing information between institutions. My local experience in France is that it is never used indeed between institutions, (so for example the hub full open concept), but yet extensively of interest for urbanizing internal construction within an institution or relative institutions.

              Cheers !

              Show
              vf Valery Fremaux added a comment - On martin's demand, here is an experience return of using extensively on MNet and starting balancing with standard WS. I drove from 2008 several projects of "global LMS urbanisation" highly based on Mnet strategies do divide LMS ara into administative independant, but yet consistant "zones". This was concommitant with the development of VMoodle virtualisation, leading to one single install governing all moodles in an array, largely Mnet bound. Pairformance is a 31 moodles array, using a Full Mnet topology (all node is bound to every 30 other nodes), The Académie of Strasbourg project proposes 70 singular school moodles in an array start connected to one central common unit. Paris Descartes University was installed with 13 VMoodle nodes in an enhanced Mnet auth integration so called MultiMnet, to resolve the "unique identity at every outside door (even unregistered)". All these projects could lead me to very extensively measure strengths and weaknesses of Mnet, from a functional and exploitation point of view : Weaknesses : 1. Key obsolescence breaking Mnet based web services / Users explicit romaing repar keys, Underlying cross platforms web services do not. We added in VMoodle a special automated key renewal (inside trust network), that works strongly since years without special care. Indeed, in case of severe perturbation (DNS break) during key renewal, this can mess largely the array, and ask me to use my massive weapon (global key renewal script) 2. Crossing information builds too many and hard to work with dependant information using remote enrolment. We actually dicard any use of remote enrolment, prefering implement a "user propagation and ask remote for enrolement" strategy, linking data much less than Mnet enrolment. 3. Multijumping from A to B, A to C and A to B to C : creating a mess of identities in C (a from A and a from B). This is easy to adress and has been resolved mostly in all our installs. 4. In some topologies (star topology), unicity of user is not guaranteed (say start moodle is S, a in A and a in B leads to 2 identities in S : a from A and a from B – we have this for public education teachers having assignation in two schools). This is under resolution. 5. Mnet has no intrinsic user identity transport when exchanging Mnet requests, the question of the remote capabilities of the calling user of the request needs to be developped in each function. My implementation of this is a bit weak and does not have standard fallbacks to drive user with a comprehensible fedback (actually makes big Moodle error, logical, but not user friendly). Apart of those real use cases and tricky situation, and apart some roughness of the Mnet code, regarding to much "higher OO conceptual implementations, Mnet as conceptual advantages in terms of service management. So let us make some advocacy in favour of Mnet : Strenghs : 1. Clearness of the platform cross service agreement : The process of cross exchanging Mnet identity makes the environment network topology predictable and drawable. 2. Service organisation : While WS also present a service level definition, this one is much less formal and clear to map and monitor. The service definition in Mnet is a real good tool to design complex multi-node topologies, and formalize network service organisation. I fear we loose that easy to view architecture in a global WS system that will not differentiate any more what are internal services (structural) and what are external services (bridges, connectors, extrinsic integration). Using actual WS service definition would lead to a big work of the administrator to build and assemble webservices on each node, while Mnet just asks to enable/disable them to build the service topology). 3. The excellent "remote view of service states" when binding symmetric services. 4. Strongly dividing load on each plaform : a 50.000 students organisation falls to 10 units of 5000 students + some shared accounts that are not o many. 5. Allows distinct decisions of adminiistration and administration delegation to school departments in an autonomous way. Say a Litterature and Humanities dpt has not same needs and organisation than a Science dpt. I noticed that initial use of mnet was thought in an open thinking of crossing information between institutions. My local experience in France is that it is never used indeed between institutions, (so for example the hub full open concept), but yet extensively of interest for urbanizing internal construction within an institution or relative institutions. Cheers !
              Hide
              simoncoggins Simon Coggins added a comment -

              I've attached a summary of the results to date with the responder names and emails blurred out.

              Martin Dougiamas I will send you the full results via email.

              Show
              simoncoggins Simon Coggins added a comment - I've attached a summary of the results to date with the responder names and emails blurred out. Martin Dougiamas I will send you the full results via email.
              Hide
              anitsirk Kristina Hoeppner added a comment -

              blueprint for decoupling Moodle and Mahara from MNet to use more modern infrastructure

              Show
              anitsirk Kristina Hoeppner added a comment - blueprint for decoupling Moodle and Mahara from MNet to use more modern infrastructure
              Hide
              anitsirk Kristina Hoeppner added a comment -

              We'd like to thank everyone who replied to the survey earlier in the year. The answers influenced the architectural proposal.

              Attached please find high level information for a proposal on accomplishing the integration between Moodle and Mahara (and other systems) in the future without relying on MNet.

              Show
              anitsirk Kristina Hoeppner added a comment - We'd like to thank everyone who replied to the survey earlier in the year. The answers influenced the architectural proposal. Attached please find high level information for a proposal on accomplishing the integration between Moodle and Mahara (and other systems) in the future without relying on MNet.
              Hide
              anitsirk Kristina Hoeppner added a comment -

              We've had the first meeting with Martin last week and the high level proposal was discussed. Notes about tasks etc. can be found on the specs page https://docs.moodle.org/dev/MNet_Roadmap

              Show
              anitsirk Kristina Hoeppner added a comment - We've had the first meeting with Martin last week and the high level proposal was discussed. Notes about tasks etc. can be found on the specs page https://docs.moodle.org/dev/MNet_Roadmap
              Hide
              brendanheywood Brendan Heywood added a comment -

              Has there been much dev work yet on this? I'm thinking about doing a rewrite of the saml authentication plugin for moodle and there is some overlap with this issue. I'm coming from a very different angle, see MDL-48887 which is around making the login flow much faster for saml (and other protocols too) by removing a bunch of redundant redirects (from 7 redirects down to 3). In order to do this really well I'm thinking of rewriting the saml plugin to embed the simplesamlphp standalone library which also has the side benefit discussed above of removing the need for separate simplesamlphp installation and configuration, and vastly simplifying the moodle side config into the auth plugin GUI and not in any files.

              It seems from this MNET discussion that auth_saml will need to become part of core anyway so I don't want to double up on effort.

              Show
              brendanheywood Brendan Heywood added a comment - Has there been much dev work yet on this? I'm thinking about doing a rewrite of the saml authentication plugin for moodle and there is some overlap with this issue. I'm coming from a very different angle, see MDL-48887 which is around making the login flow much faster for saml (and other protocols too) by removing a bunch of redundant redirects (from 7 redirects down to 3). In order to do this really well I'm thinking of rewriting the saml plugin to embed the simplesamlphp standalone library which also has the side benefit discussed above of removing the need for separate simplesamlphp installation and configuration, and vastly simplifying the moodle side config into the auth plugin GUI and not in any files. It seems from this MNET discussion that auth_saml will need to become part of core anyway so I don't want to double up on effort.
              Hide
              phil@dunlop-lello.uk Phil Lello added a comment -

              Has development work started on this yet, or is the architecture still open for discussion? Is there any specification for how the new architecture will work?

              Is there a timeline for when the current MNet will be removed? I'm considering writing a Java implementation for integration with other systems, but if a replacement is imminent, it could turn out to be wasted effort.

              Show
              phil@dunlop-lello.uk Phil Lello added a comment - Has development work started on this yet, or is the architecture still open for discussion? Is there any specification for how the new architecture will work? Is there a timeline for when the current MNet will be removed? I'm considering writing a Java implementation for integration with other systems, but if a replacement is imminent, it could turn out to be wasted effort.
              Hide
              mudrd8mz David Mudrak added a comment -

              Phil, I believe that if you build your Java app on web services provided by Moodle, it won't be a bad step.

              Show
              mudrd8mz David Mudrak added a comment - Phil, I believe that if you build your Java app on web services provided by Moodle, it won't be a bad step.
              Hide
              phil@dunlop-lello.uk Phil Lello added a comment -

              Hi David, thanks for the suggestion.

              In this instance, both Moodle and the Java app are live systems, and I need SSO between them, as well as various RPC calls each way.

              I don't think the other RPC channels would support SSO, given that most of the Moodle users authenticate against a Shibboleth/SAML2 IdP, and the Java app authenticates against LDAP. I'm considering using signed oauth urls instead, but I'm not a fan of that approach.

              Show
              phil@dunlop-lello.uk Phil Lello added a comment - Hi David, thanks for the suggestion. In this instance, both Moodle and the Java app are live systems, and I need SSO between them, as well as various RPC calls each way. I don't think the other RPC channels would support SSO, given that most of the Moodle users authenticate against a Shibboleth/SAML2 IdP, and the Java app authenticates against LDAP. I'm considering using signed oauth urls instead, but I'm not a fan of that approach.

                People

                • Votes:
                  19 Vote for this issue
                  Watchers:
                  57 Start watching this issue

                  Dates

                  • Created:
                    Updated: