Obsolete:MNET 1.0 technotes

Establishing trust relationships

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 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 have trouble.

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. When trusting a web app like Moodle, the URL itself is an important point of trust, specially if it is via HTTPS.

Work involved

• Revamp Crypt_GPG
• HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way
• Define a simple API to
  • Publish pub cert
  • Publish services offered
  • Trigger services offered
  • Create "allow users to SSO" service
    • Options: users shortlist, remote admin approval
    • Requires Auth API work and plugin changes
  • Create "allow users to enrol in courses" service
    • Options: courses shortlist, remote admin approval
    • Requires Enrol API work and plugin changes

• User-friendly admin pages
  • Establish and manage trust relations
  • Open/close services
  • Each service with an associated usage report. Examples:
    • What remote users are logging in, from where, which remote admin OKd them
    • What remote users are enrolled in, from where, which remote admin OKd them