This document outlines the plan for migrating Moodle to MyAccess authentication (actually, Shibboleth authentication).
- Update rltest3 to be the same as production Moodle
- Shibbolize rltest3
- Set up Moodle on rltest3 so that it works with Shibboleth
- Write script for modifying usernames and authentication method
- Once rltest3 has been Shibbolized, submit metadata to MyAccess, and ProtectNetwork
- Open Ticket with Remote Learner for Shibboleth work
- Guests should not be able to log into Moodle until an admin creates the account.
- UCSF users should not be able to log into Moodle until they have an account in Moodle.
- Existing users should be able to log in if the OAAIS LDAP service is down.
- How will guest accounts work?
- How are guest accounts added to Moodle?
- How will the login interface change?
- How will the two local admin Moodle accounts work?
- How do we keep unauthorized Shibboleth users from being able to log in?
- Are there any implications for the CLEAE?
- How does a Shibbolized Moodle integrate with LDAP?
How will guest accounts work?
We will have a user create an account with ProtectNetwork. Once the user creates the account, the user must tell a Moodle admin what the username is, and then the Moodle admin will have to add the user (using firstname.lastname@example.org as the Moodle account username) to Moodle. See "How are guest accounts added to Moodle?" below.
How are guest accounts added to Moodle?
Log into Moodle as an admin, then go to Users -> Accounts -> Add a new user. The "Choose an authentication" option must be "Shibboleth", and the username must be the user's Shibboleth EPPN. For ProtectNetwork, it is email@example.com. Also add First Name, Last Name, Email Address, and any other required information.
How will the login interface change?
This requires an extra screen: First screen the user selects where he/she wants to authenticate from, and the second screen shows the login form (either MyAccess or ProtectNetwork). View example on lr-cle.
How will the two local admin Moodle accounts work?
Moodle will apparently accept any valid login credentials as long as they are POSTed to the appropriate URL. To test this out (on lr-cle), go to this test login form and log in as an admin (or any GALEN username and password).
How do we keep unauthorized Shibboleth users from being able to log in?
One way is to lock First Name, Last Name, Email Address, etc., as these are required fields for an account, and if a user logs in and the user does not have an account, then the user will not be able to continue as he/she will not be able to update required fields. Of course, Moodle does actually create an entry in the mdl_user table when a user does this, but the record will be incomplete.
This seems like a hack, but it is actually the same way the LDAP (GALEN) login settings are currently configured. However, with LDAP, there is no chance of a user logging in if the user doesn't have a GALEN account, and everyone in GALEN has an account in Moodle... But this appears to be the way to limit access to anyone with a ProtectNetwork account from logging in.
So, perhaps we could have a process that cleans up incomplete Shibboleth accounts from the mdl_user table, on a regular basis.
Are there any implications for the CLEAE?
Jason does not think so, but we are looking into the CLEAE process to double-check.
How does a Shibbolized Moodle integrate with LDAP?
Moodle should not interact with LDAP at all on login. LDAP can still be used for account updates. We will need a process that runs on a regular basis and updates Moodle with data from the OAAIS LDAP service so that we can keep basic information in-sync: First Name, Last Name, Email Address... The OAAIS LDAP Service will be updated every 20-30 minutes, so we could have a process that runs, say, hourly to pick up any mods (including adds). A delete would not matter because if a person is removed from the OAAIS LDAP, then that means the person is no longer valid in MyAccess as well, so the person would also no longer be able to authenticate. We will have to look at how best to remove inactive accounts (unless this is not an issue).
Once we have more details on the OAAIS LDAP Service, I will provide details on how to sync information.