ADVANCE NOTICE:
We plan to remove our proprietary MNet subsystem from Moodle 2.3 (planned for release in over a year, June 2012 ). It causes us constant problems, is not well-defined, and only implemented by very few other systems.
We plan to redesign the functionality completely, replacing it with standard web service functions, standard protocols and probably standard authentication schemes like OAuth 2.0.
We want to work with the Mahara developers (and anyone else who may be using Mnet) to ensure a smooth changeover, but it's unlikely that the new system can be directly backward-compatible with MNet.
This means that if you use MNet in a significant way, you need to upgrade all your networked systems at the same time and reconfigure the networking.
At this stage the design for the new systems is not defined at all. My own thinking is that we should think holistically about how Moodle can share authentication and the old MNet services with all kinds of other systems, not just Mahara. If you have any ideas on what we should do and how, then now would be a good time to start brainstorming!
I would really like to see something that is as trivial as humanly possible to develop peers for. I've lost count of how many SSO solutions I have coded for Moodle but all were written from scratch because I never managed to get my head around MNet (or needed the levels of security when, inevitably, both systems were on the same subnet behind a Firewall). In reality, that would probably mean a configurable level(s) of security - or plugins even.
It would seem very sensible to use existing technologies (e.g. OAuth as you suggest) rather than reinventing the proverbial wheel if at all possible.
This seem a case of making the complex simple. XML-RPC is a suitable protocol. It is universal.
From my own playing with Mnet. A user authenticates on the auth Moodle. A Mnet connection provides a ssl connection to transfer auth and profile.
In the standard Moodle profile that gets transfered there is nothing that would compromise. IE No password.
As all session authentication is done by cookies the only risk that exists is a MIM attack using a session cookie. That risk already exists and is considered acceptable.
Just my thoughts.
Like many I only use Mnet to network Moodles. Some of mine are via the Internet. If it already uses XMLRPC then PHP had the libraries already.
When Martin suggested Oauth I groaned. More config!
Doing some reading while nurse puts my breakfast through the blender, the Oauth is rather a neat solution. It is already used by Google and Facebook. It is a library, and Moodle is already using it.
The big issue as Martin pointed out was the database migration.
Yes, I think it makes sense to use more standard mechanisms like OAuth and OpenID, now that we have them. It would make integrating with other web applications easier, and I think that OAuth and OpenID together can (with a little creativity) already do much of what MNet does.
Is OpenID viable? This company doesn't think so.
Hi, just for background purposes only. MNET was designed for Moodle-Moodle pairing. Naturally we made Mahara MNET compliant but it was really driven by the desire to network multiple Moodles for the NZ education system - that was the project. We used XML-RPC at the time but totally agree that if we can have a robust networking system that enables pairing with more systems, so much the better.
cheers
Richard
As long as there is a viable alternative and we are still able to network our various Moodle instances and Mahara, it will be fine. Our region covers half a state and we are creating individual Moodle instances for each school district. We absolutely have to have a way to connect these for cross enrollment, etc. I hope that whatever solution is chosen it will be easy to set up. I would support a solution that had SSL as an option, rather than a requirement. All of our instances will be deployed behind a single firewall so we are not so concerned about that traffic being secure.
Thanks for the heads up.
We are actively using mnet peering for co-teaching/managing courses with a variety of independent NZ Moodle sites. A loose collaboration also had Catalyst develop a patch for Moodle 1.9 that supports bulk enrolments across mnet which works well.
I can't comment on the technical architecture but would plead for whichever mechanism is selected to be able to support batch enrolment (defined roles) as well as account creation/authentication.
Our current patch (for 1.9) is based on creating a shell course on our site and mapping this to a specific course on the peer. We enrol users as students in our course shell using our own bulk enrolment process and their enrolment is mapped to the peer course. A peer can also define what roles we can enrol our users to within a course.
We were also designing a solution based on MNet to connect different moodles from our campus (aiming moodle 2.x). For our needs we found MNet not so robust as we expected (specially concerning automatic and remote enrollments, sharing of information, etc)... but with so much potencial!
I think MNet is much more interesting than simple SSO and I also share the idea that networking moodle instances may be something independent of the SSO method.
I would love (and need) to hear more about the new Moodle Network plannings!
Cheers,
susana
I agree, Susana. We need SSO to be independent of the replacement MNet. The entire reason we use MNet rather than SSO is because we don't want to expand the LDAP contexts in each Moodle instance to be global. By using MNet we ensure that students are always associated with their "home" school. This is the only way students are correctly associated with their Mahara account, too. Not to mention that Mahara does not support any kind of SSO, to my knowledge.
I am eager to see other conversations on this topic.
Currently mahara does support SAML(a.k.a shibboleth to some) and could support other SSO systems as long as someone writes a plugin for it. Although Mahara and Moodle both support SAML It will not send files from one to the other afaik when authenticated via SAML, as the integration depends on MNET.
That company's complaint about OpenID is based on dodgy OpenID providers. If Moodle uses OpenID to replace MNet, some of the more confusing parts of the OpenID flow can be avoided when you're the admin of both ends, by setting it up so that
- users don't have to enter URLs, and
- users don't need to be prompted for confirmation
(as long as both ends allow such configuration, but since we would create both ends, we can make it that way).
I would think that the integration between 2 applications should be seperate from the authentication scheme they use.
So that the administrator can set up the applications with any SSO Method (Shibboleth/SAML, OAuth2.0, OpenId) and as long as the user is authenticated on both sides with for instance a similiar username(or other configurable attribute), files/ can be transfered for that user.
Not quite got my head round how moodle exports the actual files to mahara yet but would be interested to find out how this currently works(any links or info?) to further brainstorm on any good and standards based solutions.
Have been thinking that it might be a good idea to use Web services e.g. REST or SOAP to replace the networking functionality. This would allow for any developer to easily write 3party software that could take advantage of any functions that mahara uses currently.
I'll do some more digging to see if this can somehow be done by extending the current Web Services/External Services functionality.
I have succesfully managed to extend the rest webservices server to allow for authentication by session (instead of username and passwd or token).
This means that it would be possible to allow other software to use the Webservices as long as I have an authenticated moodle session(and the permissions to use the webservice).
Does anybody know if/and why this would be a bad idea?
It might be a good idea to set up an hostname/ip-based or application based token system which would mean that you could allow only certain applications/hosts to access the webservices.
Could anyone tell me all the integrated functions(what can mahara access in moodle and the other way around) between mahara and moodle to see if all these functions can be simulated via webservices.
Another important feature of MNet is the ability of having a list of all courses a user is enrolled in, independently in which moodle instance the course resides.
For instance, I'm enrolled in course A in Moodle X and course B in Moodle Y. I May have in my course list CourseA and CourseB available (in a single course list). This is is really useful if you want to offer academics and students an integrated e-learning system on your campus.
MNet may provide a some kind of e-learning portal for different Moodle instances. But MNet as it is, may be improved in several aspect regarding this purpose.
cheers.
I'm all for OAuth 2.0, as said above the people at Google, Microsoft, Facebook, Yahoo are behind it and are already using it (although the spec is still draft). As a user/developer of MNet from Moodle to Drupal and as the developer of the Facebook moodle plugin I can see the benefit of going with OAuth.
I like the way Facebook have implemented their graph protocol - OAuth with REST under the hood (https://developers.facebook.com/docs/reference/api). Its clean and easily extended. There is a good rundown on the technicalities of OAuth on this blog: http://www.sociallipstick.com
Does anyone else think that OAuth and OpenID solutions being discussed sound very complicated? I am concerned that this solution is going to be overly complex and harder to set up than the current implementation. As several have already mentioned with the current MNet, the SSL requirements are unnecessary for some. OAuth and OpenID certainly don't sound like they will make this easier, will they?
To add, OAuth and OpenID aren't going to provide the methods to facilitate remote enrollment, portfolio services, etc with other systems are they? That would require some sort of web service like REST or SOAP?
If I am wrong, please help me out.
OAuth is much more simple than the MNet protocol. It still uses SSL (This could be made optional I guess, but it would open security holes), but it uses it in the standard way (MNet almost reinvented SSL). To use SSL the OAuth way you simply need to use https:// in the URL. The OAuth provider will need to have the SSL extension installed on thier webserver (eg mod_ssl for apache) and have SSL set up for the site. One of the really nice things about OAuth is that priviledges are set on a site-to-site and user-to-site basis. An example here might be that site A grants site B the ability to sync user profile data, user's picture, allow the user to enrol in its courses. When a user comes from site B to site A they are asked if they are happy for site A to provide user profile data, user's picture, allow the user to enrol in its courses. If the user agrees then Site B and Site A can share just that information about that user / allow the user to do those things. This could easily be extended to: sharing of grades, enroling in courses, profile information, or for single signon only (no course sharing) with other providers (eg moodles, facebook, google, yahoo, or any other site that has OAuth and you've got API keys for....)
OAuth is an authentication protocol, it's not involved in transferring data between systems for this you will need something like REST.
OpenID doesn't require SSL. OAuth requires SSL (at least for part of the flow). Though I'm sure that you're free to ignore that requirement if you control both ends.
Yes, that is a bad idea. You don't want to share the session ID, because that could be used to impersonate the user completely. Both OAuth and Moodle's web services system are designed to allow the system to limit what remote systems can do (in different ways).
I'm reading through the OAuth specs, and I'm wondering what we would gain from OAuth over a plain token-based web service that Moodle already has (i.e. the "One system controlling Moodle with a token" flow in the Web Services overview page), and whether OAuth really is suitable.
- OAuth seems to be designed to allow two systems that are maintained by separate entities to share data, whereas from what I have seen, MNet is mostly used in situations where both ends are administered by the same people, in which case, it's easy to set up a special user, exchange a token, etc.
- OAuth only gives you authenticated web services in one direction, whereas MNet is bidirectional. I think that it is possible to hack the protocol to get both directions, but that would be non-standard.
- The direction that OAuth gives us is the opposite from what we generally want. For example, in the Moodle/Mahara case, currently Moodle is the identity provider and Mahara is the service provider. That would make Moodle the OAuth server, and Mahara the OAuth client, which means that Mahara could make requests from Moodle, but not the other way around (without the above-mentioned protocol hacking). But the portfolio and repository APIs want to communicate the other way around -- with Moodle making function calls to Mahara.
- OAuth generates a token for each user, which seems a bit wasteful in this situation. For trusted systems, it's simpler to just use a single token for each networked connection.
From what I can tell, OAuth isn't a good match for an MNet replacement. Am I wrong in my assessment here?
Answering some of my own questions, 2-legged OAuth (as opposed to the regular 3-legged OAuth) would address some of these. I'm still not sure what the advantage of OAuth would be, though, compared to a plain token-based web service.
"MNet is mostly used in situations where both ends are administered by the same people" - that's incorrect. MNet was designed for separate educational institutions to share courses and students. That was the original Use Case and in that context very rare for both ends to be administered by the same people.
I agree the ideal replacement needs to be bidirectional.
regards
Richard
Richard,
When you say "bidirectional," as being the ideal. Do you mean that a users primary credentials (username password) would be transferred between instances.
John
To clarify, when I said bidirectional (I can't speak for what Richard means), I mean that each end of the connection needs to be able to make an API call to the other end.
Hi John,
No, the credentials of users is not exchanged. This is the point of MNet. It happens via an encrypted trust relationship between the LMSs, not by transferral of credentials.
Richard
Thanks Richard,
I can put the tranquilizers away. A point that we all should keep in mind, I think. We are moving into the jargon, acronyms area. With Mnet the original concept of a Hub was 2 or more Moodles or a Mahara talking to each other. Today a hub is a stand alone server used as a archive. One concept two definitions.
If I can add a wish to the list. Cohorts, needs to be broadened. Again the jargon of site wide, which to me means domain, not local machine. Make cohorts usable with the new method not only by admin but managers and teachers.
John
John, what do you mean by broadening cohorts? Do you mean that MNet users should be able to be placed in cohorts? Or that MNet users should be able to administer cohorts? Or...?
To clarify, by "same people", I meant that it's generally used for multiple Moodles within the same institution (but, e.g. different departments), whether or not they're actually administered by the exact same people. In this case, the administrators generally know each other, and have a secure channel to exchange credentials, and have some level of trust of each other. At least, that's the most common use from what I've observed. Whether or not that's the use case that it was originally designed for is a different matter. And it could be that I am unaware of other uses that are common.
Either way, I've thought through the flows, and both OAuth and token-based webservices need to be initialized by exchanging some sort of secret token, so the setup is essentially the same between the two. The only things that I can think of that give OAuth an advantage are 1. slightly better security, since requests are signed (but if you really care about security, you should be using SSL/TLS), and 2. it's more "standard" (but token-based authentication is super-simple -- it's just an extra query parameter).
I don't suppose either of us have undertaken extensive studies on its common usage. All I can say is that MNet was designed (conceptually by myself) in order that separate institutions could establish fine-grained (sharing this student but not that one) federation relationships to achieve networked education. And this is how it is used in New Zealand.
Security is often paramount but I'm not the guy who comes up with the technical solutions for these things - so I'm pleased to see the discussion and your input thanks.
Richard
No, I haven't undertaken any sort of studies as to what the common usage patterns are, and my remarks are mostly based on what I've observed in this forum. Part of the point of my post was to find out if my impressions were incorrect. If a more loosely affiliated network is what is used in New Zealand, I would definitely consider that a "common usage".
Just some really quick thoughts from someone who doesn't know mnet anywhere near as well as I should, there are two main things to think about here:
1) Cross-site authentication. This seems to be well met by OpenID/OAuth2 etc. Moodle should be a better part of the wider internet here as both a consumer and a producer.
2) Pulling/pushing data between systems like multiple Moodles or Mahara etc. To me this sounds like a job for our Moodle 2.x web service infrastructure, and if it needs more security then let's add that or recommend users run everything under https. We just need to simplify the complex set up we have now.
run everything under https
Well, that's basically what MNet does pretty well - it encrypts and signs the XML-RPC communication and looks after SSL keys exchange and regular updates. HTTPS does not deal with this part.
From my point of view, MNet could be converted to just another web-service protocols in Moodle (besides plain XML-RPC, SOAP etc). This way we could profit from the solid web services framework without loosing the MNet unique features.
IMHO, if you use OAuth for cross-site authentication, you may as well use it for web services as well. Anyways, I have an OAuth authentication method working for web services, so it will be easy to switch methods, or even use different methods for different peers.
As far as switching the current MNet system to web services, I can see two big issues:
- Currently, with web services using token-based authentication (and my new OAuth authentication method), you can only select one service for each token, but with MNet, you can select multiple services that each peer is allowed to access.
- With MNet, each function call has an implicit parameter, which is the remote host that is calling the function. With the current web services system, the only way I can think of to get the same type of behaviour is to enforce that each MNet peer must be linked to a different user.
At the time I wrote the parent post to this, 2.3 seemed a long way off! Now it's nearly here, but a solution to replace Mnet has not been fully decided, let alone implemented. As such, nothing will be removed or changed and small bugs will continue being fixed in Mnet support for a while yet.
However, Dan Poltawski, who joined Moodle HQ in Perth today (yay!!) does have this as one of his first tasks. He'll be coming up with some suggestions for Oauth2 implementations for Moodle and new web services to allow great integrations with Mahara. Then we'll be putting those to the Mahara community and hopefully working with them to come up with a good joint plan going forward so that Moodle and Mahara can work well together.
LOL Helen beat me to it adding to the docs http://docs.moodle.org/22/en/MNet
Good that it is clarified now and good luck with the job Dan (you need to edit your Moodle profile!)
Hi Martin
Last year I under took (with funding from the Ministry of Education NZ) to implement a SOAP based web services stack in Mahara as a plugin https://gitorious.org/mahara-contrib/artefact-webservice . This has since been extended with XML-RPC, REST, and OAuth v1 authentication (operates as an IdP - there is no reason why client infrstructure cannot be implemented). The entire stack was based on the excellent work done in Moodle, so they are highly compatible to the point that token, and user based auth function in the same way if necessary. As a trial I made a few small modifcations to the MNet stack in Moodle, and managed to get that working against the new Mahara Web Services stack - not that this is necessary, but it gives flexibility to possible paths forward.
Since then, a lot of work has been done by the Mahara development team to get this into core, and with luck and determiniation it could be there in Mahara 1.6.
I put this out there as a possible path forward for solving atleast the immediate Moodle/Mahara integration dilemma.
Cheers,
Piers Harding.
Thanks for chiming in there - thats really useful information which I was on vaguely aware of.
cheers,
Dan
While in principle it is great to see Moodle moving forwards, in some areas the changes introduced have a far reaching effect on courses designed and developed with third party plug-ins and partnering software in mind. The removal of MNET support is a backward step when carried out without a replacement system already in place. I have Moodle working together with Mahara, and many assignments and projects in place. In order to keep pace, and maintain security I have to update my Moodle platform regularly, and I now find that with the step to 2.4+ that all my work has effectively gone out the window. I really hope that Moodle/Mahara are going to find a solution to this highly valuable compatability issue since I am sure it affects more people than just me.
MNet has not been removed yet, and will not be removed until a replacement is developed. Obviously, the 2.3 timeline that was originally planned was too optimistic.
Has the planning for this progressed any further since December?
Thx,
Nick
OK, so I've started an issue so we can make some headway on this!
MDL-40905 is the issue to watch if you interested in seeing MNet die.
Hello,
Thanks to everyone who responded to our survey earlier in the year where we asked how MNet is used in the Moodle and Mahara communities. You can find a discussion proposal for the future implementation on the tracker item. Comments are welcome. It is kept at a high-level view at the moment.
Thank you
Kristina
I am speaking as an outsider, it that I have never used MNet or Mahara, but the plan looks sensible for a high-level approach. Good luck with it.
Thank you, Tim. Our developers could discuss the proposal with Martin last week and the specs now have some high level tasks to be prioritized and fleshed out more. See the specs page for more info.
Cheers
Kristina