Ideally, it would be nice to have a master on-premises directory that controls membership in the institution. This would be the reference. All other services would be synchronized to this and have a single-sign-on (SSO).
To be specific, we would have our on-premises directory on open LDAP (Light Directory Access Protocol) and our services such as Moodle, Google G-suite Education, Office 365 Education, and any WordPress CMS (intranet for example) would somehow have SSO and be synchronized to our LDAP directory.
The problem with the above situation is that such an implementation is not straightforward and has problems. I will list a few of them below:
- It is very difficult to manage an LDAP. You will need some sort of a spreadsheet and custom software to synchronize to the LDAP. In any scenario, you will need to have custom software to drive the LDAP synchronization to your admission process, your exit process, etc., so this is patently untenable for small schools.
- If you start with a mix of independent tools without SSO and synchronization, it is difficult to introduce SSO and synchronization midway due to impossibility of syncing hashed passwords, etc.
- Relying on your on-premises LDAP is risky as it is potentially a single point of failure. I am not talking about LDAP being on a bare metal server on your premises. Even if the LDAP is on your VPS in a cloud, to rely on that solely, seems risky.
- SSO is not as important as it is to synchronize membership. When members leave, it is important that their accounts on all tools be removed automatically after data is archived.
So why not make Google or o365 as the directory reference? The main issue with this is the difficulty of administering accounts on these systems. Take Google for example: It is not possible to use a CSV to bulk delete. Further, one is limited to number of accounts that can be created per CSV upload and various other limits. Even bigger issue is that of creating groups conveniently.
In light of all this I decided to make Moodle directory as the reference.
- It is very easy to manage user accounts and cohorts using CSV files, no limits on size of files, number of accounts per upload, etc.
- It is very easy to suspend users and remove members form cohorts in Moodle.
- Moodle has a variety of plugins that can help in synchronizing to other services. It is also relatively easy to modify existing plugins as I have done here.
What is the SSO situation? The LDAP is not used for authentication by any system, it is just used to control membership (provisioning). So the following will be the SSO scenario:
- Users can login to Moodle either by using Moodle login credentials or SSO using Google G-suite account authentication.
- Users must login to their Google G-Suite account using Google authentication.
- Users have SSO access to their WordPress intranet sites via the Moodle LTI. This is especially handy if your intranet sites also have e-commerce enabled.
- Users can SSO to their o365 accounts using Google Authentication.
Thus the user is required to remember only their Google login.
The synchronization and SSO methodology is laid out in detail in a separate posts below:
Synchronizing LDAP to Moodle (Moodle is directory reference)
Synchronizing Google G-Suite with LDAP (LDAP is directory reference)