The Library would like to move away from GALEN accounts for authentication, which means we need to find a different authentication system. The obvious choice is MyAccess, but we need to make sure MyAccess really is the best choice, and if so, how exactly should we use MyAccess, as they have several options to choose from.
- MyAccess Landing Page (not really an option, but it should be included for completeness)
- MyAccess Virtual Host
- AD via Library Login
- MyAccess AuthN via Library Login (like the VPN)
Shibboleth is probably the fastest way to get up-and-running with MyAccess authentication, however, it suffers from the following issues:
- No Forgot ID link
- No Forgot Password link
- Branded as "Federated Login" which can be confusing to users
Even if the Forgot ID and Forgot Password links (and soon New User? link) were provided on the Shibboleth login page, when a user is finished using them the user is returned to the MyAccess login page. Since the MyAccess login page and the Shibboleth login pages are identical, the user then logs into MyAccess and does not see links to the federated application he/she was trying to access. This has proven to be confusing to users. (MyAccess needs to fix this problem regardless of whether or not the Library uses Shibboleth.)
Remote Learner is able to provide Shibboleth for Moodle. However, we do not know if there are additional costs associated with this setup and support.
Guests could also use Shibboleth via a free Shibboleth Identity Provider like ProtectNetwork. ProtectNetwork allows a user to set up their own account (which can then be used for Shibboleth, and chosen from the InCommon WAYF page), or an administrator can be established to create accounts. The Library could make use of both user-created accounts, and administrator-created accounts.
MyAccess Landing Page
Most if not all people are probably in agreement that the MyAccess Landing Page is not a viable option since it hides Moodle and the Wiki behind MyAccess. In essence, going with this option wipes out the branding that the Library has put into both of these initiatives. Furthermore, it makes it impossible to send authenticated Wiki links to users as the MyAccess login process will render the link unless. If the user is already logged into MyAccess, then the link would work, however, this difference is another opportunity to confuse users.
MyAccess Virtual Host
The MyAccess Virtual Host is a service that MyAccess could provide (they currently do not offer it, but might be willing to). It is a hybrid between the landing page and Shibboleth, in that you use MyAccess for the login page (and actually proxy all traffic through MyAccess), but you do not use the landing page. Essentially, once the user authenticates with the virtual host method, the user is sent directly to the service he/she wanted (like Moodle or the Wiki) instead of being shown the landing page.
Given that MyAccess has not offered this service to anyone yet, it may not be possible, and if it is, does the Library want to be the first client to use it?
AD via Library Login
Given that AD does not have the entire population that would need to authenticate to Moodle and/or the Wiki, AD is probably not really a viable option. AD would also require the Library to install and run its own AuthN service. (See MyAccess AuthN via Library Login for more details about this.)
MyAccess AuthN via Library Login (like the VPN)
The VPN has already paved the way for external customers to use the MyAccess credential store without having to use the MyAccess login process. Although MyAccess has circulated a document about allowing access to the TAM LDAP credential store, it remains to be seen what kind of service they are going to offer for this.
In order to do this the Library would have to implement its own login interface. For this we could easily use something like the Jasig Central Authentication Service (CAS), as it was designed to do AuthN, and do it well. We could simply point it at the MyAccess AuthN LDAP server and then have simple MyAccess-enabled AuthN for all Library services (not just Moodle and the Wiki). This way the Library would be solely responsible for all AuthN migrations/integrations of Library systems. We would have the benefit of using the universal MyAccess credential, yet be in total control of how we integrate our applications into the system.
Doing this would also allow the Library to offer guest accounts if need be. By using a service like CAS, the Library could offer the same login screen to users with MyAccess accounts and users with guest accounts. CAS can be configured to authenticate against any and multiple simultaneous back-end systems.
Given that the Library currently does not host any applications that are multi-instance applications, i.e., has 2 or more instancing service traffic simultaneously, there would be no reason to run CAS as a multi-instance application, which greatly simplifies the system.
To see how CAS would work for Moodle, try the following proof of concept:
Moodle via CAS
You will have to ask Lucas to covert your account from GALEN to CAS in this instance of Moodle.
Current Issues with MyAccess
As noted in the Shibboleth option above, MyAccess currently has a problem with how it does password resets, forgot ID, and soon, new user self-activation. The problem is that when the user has performed one of the aforementioned tasks, the user is sent to the MyAccess login page. This is fine if the user was intending to use an application on the MyAccess landing page, but that does not work for the VPN and for Shibboleth (and currently, there are not Forgot ID and Forgot Password links on the Shibboleth login page).
This problem can be easily solved by the MyAccess group by simply providing some options for a user once he/she has changed his/her password/requested his/her ID/requested activation. For instance, it could have a link to the main login page, links to the 3 Shibbolized applications, and a link to the VPN. Additionally, if the Library were to use either Shibboleth or it's own Login system, the page could provide a link back to the library login page.
If the Library were to implement its own AuthN service, like CAS, the internal services which could use it are:
- Confluence Wiki
- UCSF Portfolio
- Ilios II...
GALEN itself, which is the current authentication system, is used by several other services:
- GoPrint, commercial desktop software for user patron management
CAS can probably not accommodate the GoPrint system, but neither could Shibboleth or any other MyAccess authentication system (unless GoPrint was configured to talk directly to the MyAccess LDAP server).
There is probably no reason CAS could not be used by SOM if the Library were to implement it. Furthermore, there are probably some other services that could use the Library AuthN service, like Ilios, for instance.
If the Library were to implement its own AuthN service and it became wildly popular, perhaps the Library could offer the implementation to OAAIS so that it could be run by the MyAccess group.
However, perhaps this is overkill, and the Library should just use Shibboleth, as it is already a service which is offered by OAAIS. Shibboleth will also allow us to handle guests (see next section).
Guest Account Management
What do do about guests? We know the following about guests:
- We have them, so, that means we need to be able to authenticate them
- We need to be able to create guest accounts in a timely manner
- OAAIS is not going to handle guests in MyAccess or AD anytime soon
- Whatever solution we come up with should work for all Library services
How other schools manage guests:
Outsource Guest Identity Management
ProtectNetwork provides a real option for guests, even if using CAS (as CAS has an OpenID option, and ProtectNetwork provides an OpenID service as well as a Shibboleth service). By using ProtectNetwork for guest/visitor ID management, we get the following benefits:
- We don't have to run any infrastructure for managing guests
- Guest account creation can be done by the end-user or by a Library administrator
- Guest account creation is immediate, i.e., no need to wait for some cycle to kick in for an account to be created, nor is there a need to wait for a department's Identity Worker or OAAIS to create the account
- A ProtectNetwork account can be used by the user for accessing other Shibboleth-protected resources (like the UCLA Spaces wiki), i.e., this one solution solves the problem for all Library guests
No matter what solution we use, we are going to have to migrate the account information in, at the least, Moodle and Confluence. There are two aspects of account migration:
- Accounts for guests/visitors
Username migration should be fairly simple. In Moodle this is simply a matter of converting GALEN usernames to MyAccess (or AD) usernames, and changing the authentication type (from 'ldap' to 'shibboleth' or 'cas'). This can be done via a one-time script run to update usernames.
Updating Confluence usernames should be just as easy, however, Atlassian does not officially support the changing of usernames. They do have information on their site about how to do it, with a note that it is unsupported. Regardless, if we are going to migrate off of GALEN accounts, we have to do username modifications.
In both Moodle and Confluence, changing the username will not affect access rights, content, etc., for the user.
Accounts for guests/visitors
There are roughly 300 accounts in GALEN that have a status of
visiting. This means that these 300 or so people who will have to have accounts created in a new guest management system, and then their accounts in Moodle and Confluence will have to be mapped to their new usernames. Perhaps some of the current usernames would be available in the new guest management system, and in that case no mapping would have to be done. However, we can't be guaranteed that, so we need to be prepared for migrating all of these accounts.
If we were to use ProtectNetwork, we have two options:
- Users could create their own accounts and then tell the Moodle/Confluence/Library admins the username
- Moodle/Confluence/Library admins could create the accounts for the user and then tell the user what their new username is, and how to access the site, etc. – actually ProtectNetwork has an 'activation via email' option for when an admin creates an account
Needless to say, coordination with these 300 users will be imperative. Timely notification to all users will also be of paramount importance.
Pros/Cons of Outsourcing Guest Identity Management
The pros for outsourcing guest identity management are obvious:
- Gets the Library out of the Identity Management business
- No more GALEN accounts means no more 24/7 monitoring and support of the system
- By using a 3rd-party system the Library can emphatically state that, "we know very little about these people"
The cons of outsourcing are:
- Do not have complete control over accounts (however, ProtectNetwork does give extensive control over an account, and even what a user is entitled to access)
- The outsourced identity provider could go out of business
- If a user is a guest and then gets a UCSF ID, and hence a MyAccess or AD account, then the user will have to be migrated to the new username
- Cost: ProtectNetwork charges per SP for using their service. With up to 4 SPs, this will cost roughly $2000/year
Item 2 above is an issue, but perhaps not a very big one. UCLA has been doing this for a while, and it is a risk they are willing to take. Demand for services like ProtectNetwork are only going to grow in the future, so the likelihood of it going away are relatively small. UCLA, UCOP, Internet2, and InCommon all accept ProtectNetwork-assert authentications.
List of all institutions using ProtectNetwork
Item 3 above is a red herring, as that is an issue with any hybrid system, i.e., a system where regular and guest accounts are not managed in the same system. In other words, we would have this problem no matter what solution we implement.
Diagram of Shibboleth
The following diagram provides a basic overview of how using MyAccess accounts via Shibboleth for UCSF students/faculty/staff/affiliates/etc., and ProtectNetwork accounts via Shibboleth for guests:
Updating Account in Moodle
Updating account to work with CAS
To update an account in Moodle to work with CAS, this is all it takes:
update mdl_user set username = '<new username>', 'auth' = 'cas' where username = '<old username>';
This was performed with my Moodle account on
lr-cle and the course for which I was enrolled was there after logging in again as user alps (via CAS). A more extensive test should be conduced with another account, but this does appear to be all that is necessary.
Simple Moodle CAS integration
ProtectNetwork Administrator Accounts