Child pages
  • Moodle MyAccess Integration Plan
Skip to end of metadata
Go to start of metadata

Overview

This document outlines the plan for migrating Moodle to MyAccess authentication (actually, Shibboleth authentication).

Technical Plan

  1. Update rltest3 to be the same as production Moodle
  2. Shibbolize rltest3
  3. Set up Moodle on rltest3 so that it works with Shibboleth
  4. Write script for modifying usernames and authentication method

Administrative Plan

  1. Once rltest3 has been Shibbolized, submit metadata to MyAccess, and ProtectNetwork
  2. Open Ticket with Remote Learner for Shibboleth work

Requirements

  1. Guests should not be able to log into Moodle until an admin creates the account.
  2. UCSF users should not be able to log into Moodle until they have an account in Moodle.
  3. Existing users should be able to log in if the OAAIS LDAP service is down.

Outstanding Issues

  1. How will guest accounts work?
  2. How are guest accounts added to Moodle?
  3. How will the login interface change?
  4. How will the two local admin Moodle accounts work?
  5. How do we keep unauthorized Shibboleth users from being able to log in?
  6. Are there any implications for the CLEAE?
  7. 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 username@idp.protectnetwork.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 username@idp.protectnetwork.org. 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.

  • No labels

22 Comments

  1. QUESTION:  With Shibboleth/MyAccess authentication, will unauthenticated users be able to enter a full Moodle URL (e.g., a URL to a course or course resource), be presented with the authN screen, and then be directly taken to that course or resource after authenticating? This is a MUST HAVE.

    1. You mean a URL like this:

      https://lr-cle.library.ucsf.edu/mod/forum/discuss.php?d=2480

      If yes, then the answer, too, is yes, this works.

      Moodle seems to handle the "where did the user want to go" after authentication the same way regardless of authentication mechanism.

  2. QUESTION:  On the login page, users have to select their organization. I think we might get some complaints about this extra step (that's how it might be received). Would it be possible to assume that the user is a member of MyAccess and default to that login page. And on that page, include links to the other login method (e.g., for guests)?

    If it's not possible -- if we must ask users to first select their organization -- then we are going to need to come up with a reason why is must be this way.

    1. The short answer: We can't do an automatic redirect because MyAccess does not support customized text on the login page (e.g. like the way UCLA has customized text on their Shibboleth login page), and hence, guests (people with ProtectNetwork accounts), will never be able to choose their login option. So, this is a technical impossibility.

      The long answer: Anytime you give up control of authentication, you almost always have to add an extra step. It is something that people eventually get used to. At Berkeley, almost every application developer/business owner wanted to have a "landing page", i.e., a page people would go to before doing the authentication (in other words, the original login page, but with no username and password form). There are well over 300 applications at UCB which use the central authentication service, and almost every one of them has a landing page which has a link or button which reads, "Login via CalNet", which then takes the user to the login screen.

      With Moodle, after you log in once, your previous choice is remembered so that you do not have to select the appropriate option from the drop down list again; at least it is one less step. But I do not see (not at the moment anyway) a way to forego the "choose your login option" page.

      1. You won't get an argument from me, but I can tell you now that there will be complaints. We are adding an extra step that we didn't have there before. All it takes is one or two SOM students to complain about something and SOM will tell us they would like it fixed/improved. UCB's experience is good, and we should point to it as a standard practice (though there are a lot of folks here who are so used to living inside the UCSF "bubble" that they can't or won't relate to the experience at other campuses). So what this means is that we need to be ready with an explanation why this is "impossible" (a dangerous word to use, because we know that nothing is really impossible), or, very very difficult to implement (i.e., expensive and/or something that OAAIS has to support). Don't underestimate users' ability to focus on the inconsequential. And it's my department that has to deal with it.

        1. We may need to rationalize it like this (as an example):

          1. Moving to one username and password (MyAccess) is a benefit for everyone on campus, and is being encouraged from the highest levels (I wish they would just make it a requirement...and maybe the new CIO will do just that).
          2. Using MyAccess requires using Shibboleth because:
            1. It is the only MyAccess solution that allows for guests
            2. Since MyAccess itself does not have guests, we must use an alternate system for them, which means we have to use Shibboleth (it becomes a circular argument)
          3. Until MyAccess allows for customized text on the Shibboleth login page, we can't do an auto redirect

          So, this leaves us with two avenues for the future:

          1. MyAccess supports guests, and, therefore, we do not have to use ProtectNetwork, so then we could use the auto redirect
          2. MyAccess supports customized text on the Shibboleth login page, so we can then provide an option for guests who need to use ProtectNetwork
          1. This is great. It makes the case and explains the reasoning. We can also add something about how we MUST move off of GALEN Accounts as it does not meet modern security standards, etc. Thanks!

  3. QUESTION:  What about Mahara? Have we considered how this change will effect Mahara?

    1. Funny you should ask.  Lucas is working on this.  We expect it to be pretty straightforward, but we'll see for sure...

  4. iTunes University:  I'm adding comments about the other systems that need to use Shibboleth/MyAccess. It definitely makes sense NOT to use GALEN as we start this service. For iTunes U

    • Guest access will be necessary.
    • Will include both public and private content. There will be a public section where no authentication is required and a private section where users must log in.
    • Mobile:  iTunes U does have a mobile interface (i.e., iTunes on the iPhone, etc.). While on the surface this wouldn't appear to have any impact on authentication, it may actually have an impact since we may need to direct users to the public and private sections via a mobile web page. I'm taking this from Columbia University's iTunes U implementation where they appear to allow users to select the Public or Private versions. When selecting the Private, they are sent to a login screen. We may need to do something similar.

    There may be other issues, but these might not become evident until we get into this.

    1. I have read through the docs for iTunes U, and it seems to be pretty straight-forward, as Apple is using/can use Shibboleth.

      As for a mobile inteface, it would be very easy for us to make an iTunes U page on the mobile app, and have links to both content. Unfortunately, the MyAccess login page is not mobile-friendly, however, it seems that neither is the login for Columbia.

  5. Confluence Wiki:  This will also need to use Shibboleth/MyAccess. Guest access will be necessary.

    I expect that the schools (esp SOM, which uses the wiki) would want the wiki to use the same login as the CLE; i.e., having the wiki use GALEN while the CLE (and iTunes U) uses MyAccess might be a problem. Not that we'd want to go this route, but we should be aware of the problems it could cause.

    1. We are in the process of planning the Confluence migration to Shibboleth. Unfortunately, from a technical aspect, it is a bit more difficult than Moodle, as Confluence was not designed to have usernames change. We will be getting this testing underway next week.

  6. QUESTION:  How will account expiration be handled for guests? Is this included with ProtectNetwork, or will this need to be handled in some other manner? It will be important that (a) accounts have expiration dates and (b), they be renewable.

    1. If we manage users ourselves we can set expiration dates, but if users create their own accounts, then we have no control over the account (and the account lasts "forever" as far as I can tell). For the latter, that would mean managing the users manually in Moodle and the other systems.

    2. How is the expiration of guest accounts handled in GALEN now?

      1. We set the expiration date in the GALEN Account interface. When an account expires, the record remains in Moodle. Users can't access it until the account is renewed. We don't need to do anything in Moodle during this process (actually, we never have to do anything with the accounts in Moodle -- it's all handled outside).

        1. I will ask Rich to give me an overview of how this works internally with GALEN Accounts.

  7. Question about the ProtectNetwork account creation page (from above). This page/form seems rather ticky-tacky. It's formatted poorly. It's not very attractive. It asks for info we don't care about. And it has ads on it. Do we have any ability to create our own page? What are our options with regard to modifying this page, or creating our own?

    1. Amazingly, the ProtectNetwork form does not have an hidden fields or a CAPTCHA to prevent remote submission of the form. So it would be feasible for us to host a form that collects the information first and then posts it to ProtectNetwork. Of course, we would have to be vigilant to make sure any changes to the ProtectNetwork form do not cause problems for our form.

      1. This sounds kind of kludgy. Do we have any other options? I'm concerned that some folks might balk at this form, it looks so weird and unprofessional (and unbranded).

  8. Another issue we probably will have to address is account retention in Moodle. Currently, with GALEN Accounts, the corresponding Moodle account remains when a GALEN Account expires. When a GALEN Account is set to Public (or is deleted, which doesn't happen much), the Moodle account is deleted. I imagine we will have to determine how this will work with MyAccess.