View source

==WARNING!   THIS DOCUMENT IS HISTORICAL AND OUT OF DATE==

The best place to start for all this would be [[Community hub]] and [http://docs.moodle.org/en/Category:MNET MNET].


<p class="note">Draft -- ''Warning: Braindump in progress'' --[[User:Martin Langhoff|Martin Langhoff]] 12:40, 20 July 2006 (WST)</p>

== Overview ==

The Community Hub development is taking shape as a plan with two parts: 
* Build infrastructure that will support the Community Hub / Moodle Network
* Build the desired services and UIs on top

Right now, the focus is on putting together a few pieces of infrastructure that support the moodlenet ''and a whole lot of other things'' :-) In other words, the goal is that, for the plumbing that we need to build, we want to build it simple and generic, so it can be easily understood and used by other services, perhaps extensions to moodlenet, or other things entirely. 

Most of this (long) page is about the infrastructural plan. Here is a quick perspective of the overall effort:

* Infrastructure & plumbing
** Get multi-auth done
** Fixup any issues with multi-enrol
** Build a P2P RPC mechanism -- the Moodle-Network plumbing on top of XML-RPC
* Infrastructure - stage 2
** Define RPC conventions that follow Moodle's own /mod /auth and /enrol conventions
* Services and UIs
** Build a nice MoodleNetwork admin UI to configure which hosts or federations you trust
** Build an easy mechanism to maintain 'federations' of hosts (to run on moodle.org?)
** Build auth/mnet for SSO
** Build enrol/mnet for enrolment
** Build repository plugin (for new API) so that a foreign Moodle can be treated as a repository
* Services and UIs
** Tied to enrol/mnet admins will want to see good reports on remote users enrolled in local courses and viceversa.

== Older technical notes ==

Stuff below this text is older, may or may not be current.

== Trust relationships and encryption notes ==

The community hub is formed by Moodle installations establishing P2P-style trust relationships. Once those relationships have been established, each Moodle can offer services from other trusted nodes, and use the offered services.

We need to define key infrastructure for managing the trust relationships, probably using a public key encryption scheme. Currently looking at...

=== Core encryption/signing infrastructure ===
* '''Using [http://php.net/openssl PHP's integrated OpenSSL] functions. This is a strong contender, as it offers a good key creation, signing and encryption infrastructure.'''
* Using GPG via
** Crypt_GPG - a proposed PEAR package, wraps around the gpg binary. We are lucky and v0.20 is offered under LGPL, though it depends on PHP5 for its error handling (easy to fix).
** TinyPHP or something similar. See DIY risks.
* Using PHP's one mcrypt functions. See DIY risks.

DYI risks: we are not actually crypto developers, so if we go out an implement message signing ourselves there is a good chance we will miss a subtle point and end up with a horribly weak implementation that we will be very proud of.

=== Key generation and storage ===

Moodle installations should be able to generate keys or load preexisting keys. GPG tends to want the key as a file, so the root of moodledata is a reasonably good place for it. Unfortunately, it is also often world-readable. 

'''Note that the key handling will never be as secure as personal GPG keys can be. The keys and the encryption machinery have to be accessible by www-data. So in most cases any user with shell access to the server can impersonate your Moodle install.'''

=== Key exchange mechanisms ===

* Each Moodle can publish its GPG public key openly in a standard url.
* Optionally, public keys can be exchanged out-of-band and loaded manually
* We do '''not''' want these keys to show up on established GPG keyrings, and it is probably overkill to establish a moodle keyring. URL itself is an important point of trust -- see next point.
* Maybe '''the 'Register Moodle' database that Moodle.org maintains could make your site keys optionally available in a searchable/browsable directory''', and provide some means of requesting a peering arrangement -- even if it is just listing the main admin's email address.

=== URL as a point of trust, and HTTPS problems ===

When trusting a web app like Moodle, the URL itself is an important point of trust, specially if it is via HTTPS. We could say that the trust levels are

* Bare IP-based HTTP URL: the admin controls the server.
* Bare name-based HTTP URL: the admin controls the server and DNS.
* Self-signed HTTPS URL: transactions are also encrypted, and we are less vulnerable against MITM attacks.
* CACert-signed HTTPS URL: there is some assurance of server administrator identity.
* Paid CA signed HTTPS URL: there is some assurance of server administrator identity and money ;-) (Actually, CAs do some due diligence to check that Amazon.com is actually Amazon Ltd.)

However, the http clients we have in PHP are brittle and hard to use in most of these cases:

* Hard to get https support (curl compile options, non-free dependencies)
* Hard to get meaningful errors when the certs aren't good. PHP's libcurl support has the needed bits and pieces, but it is hard to access them directly when using a library such as nusoap.
* Hard to register an "unofficial" CA such as CACert.

=== Encryption and performance ===

Full GPG encryption is costly. To support high-traffic scenarios we should use GPG to setup the dialogue, trade a randomly generated session key, and then continue with symmetric encryption using that session key. 

Note that this assumes we are being 'stateful' where we work on top of a stateless protocol. So we should cache the session key, and have an explicit expiry for it. If we are close to the expiry, negotiate a new one. Which leads me to...

=== Encryption and clocks ===

Moodle nodes should be on reasonably sync'd up servers. Part of the key setup process needs to check whether the system clocks are reasonably in sync.

=== Alternative: Use HTTPS infrastructure (or not!)===

One does wonder 

* Why are we signing/encrypting all this stuff when we use HTTPS?
* Why are we trying to manage our own key distribution and trust mechanisms if we can use HTTPS's?
* Why struggle with key security when Apache's SSL implementation does a kind-of-reasonable job of protecting the private keys?

In a sense, we are making it much, much harder on ourselves. However, there are several threshold issues

* Not all users can use HTTPS easily -- configuration is hard. We aim to make configuration ''very easy'' as soon as there is a gpg utility in the path. Setting that path if it's not the default should be the only hard thing in our scheme. 
* Apache's SSL private keys won't be useful to authenticate as an HTTPS client. We need both. Our scheme is of symmetric peers, on top of HTTPS but the HTTPS infrastucture is client/server.
* There may be many Moodles in the same HTTPS host sharing the same keys -- (this can be worked around though).

== Base API ==

Should be very easy to extend -- not sure if the services themselves can be cleanly pluggable as they will surely involve serious core Moodle changes, but the API should not be constrained by preconceptions.

Each service can use the core protocol or break out and do its own thing. We do need to ask several questions, however, and so it is a good idea to define an entry point and a base RPC-ish protocol.

=== Base protocol ===

* Need to define whether to use SOAP or XMLRPC. 
** Functionally equivalent
** XML-RPC simple, easier to debug
** SOAP has more in the way of introspection -- which may be of use
** The library '''must''' let us manage HTTPS cert stuff
** The library '''must''' let us encrypt/sign the payload
* Even if Moodle has other XML-RPC or SOAP entry points, we want a segregated entry point (url) for security/auditability purposes. You can eventually lock it down via httpd.conf / .htaccess
* Version the protocol?
* Declare "prefix" namespaces for each service for extensibility.

=== Services ===

=== Simple UI and implied promises===

Outline of what I'd expect a site admin to see when looking at the relations with a given host X:
* Offer Services
** Allow users from X to SSO here {yes/no} {see report} 
** Allow users from X to enrol to courses here {yes/no} {only courses from list/category} {see report} 
** Allow admins from X to enrol users to courses here {yes/no} {only courses from list/category} {see report}
** (maybe) Allow admins/teachers from X to retrive course zipfiles (without user data) {yes/no} {only courses from list/category} {see report}
** (If moodle has a LOR behaviour) Allow admins/teachers from X retrieve published LOs. {yes/no}
* Use Services
** Remote server X allows all  users from this Moodle to SSO. Allow? {all/some/no} {see report} {manage allowed users}
** Remote server X allows nominated users from this Moodle to SSO. Allow? {yes/no} {see report} {manage allowed users}
** Remote server X allows users from this Moodle to enrol interactively to (all/some/no) courses. (informational message only)
** Remove server X allows administrators to enrol users to (all/some) courses. {enrol users}
** Remote server X allows administrators/teachers to retrieve course zipfiles. Use as source? {y/n}
** Remote server X allows administrators/teachers to LOs. Use as source? {y/n}

=== User SSO ===

You know you want it! ;-)

=== Enrolment ===

There are 3 behaviours defined
 
* Allow/disallow interactive enrolment by 'remote' users. This means changes on the 'server' side, and all we need to do is to work on the enrolment infrastructure (or the manual plugin, but that could leave custom interactive plugins vulnerable). 
* Manual enrolment (by admin or teacher) is always still available. The students page should however indicate the source of the user.
* Remote admin can enrol. This will need protocol support and possibly via an enrolment plugin.

==See also==

* [[Community hub workplan]]
* [[Community hub progress]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=50247 Discussion at General Developer Forum] 

[[Category:Developer|Community hub technotes]]
[[Category:MNET]]