gdmr, February 2015
Summary: no, we should maintain our own independent authentication system. There is no strong driver towards migration, and several good reasons not to. For example: we would lose iFriend access to AFS, svn and coltex; "Informatics-only" content would be harder to implement; it would introduce outside dependencies which could prevent users from working; we would lose the ability to diagnose and manage security incidents and login problems. There would also be a not-insignificant cost and disruption in migrating.
One of the principal design goals of the DICE project was that it should use a single-sign-on system: this would promote ease of use; it would allow for strongly-authenticated filesystem access; and it would allow a number of system- and infrastructure-management tasks, to be properly authenticated. This was done by setting up an Informatics-wide Kerberos authentication system, with "key distribution centres" (KDCs) spread across all of our sites for robustness. Our system configuration system ("lcfg") and later our account management system ("Prometheus") were integrated with this, to avoid unnecessary security weaknesses as well as to help considerably with operational efficiency. Our Cosign-based web authentication builds on this infrastructure, and our iFriend system was added in such a way that it can be used for "traditional" Kerberos-based applications, such as subversion, as well as for web sites.
A central University-wide system (EASE) was subsequently set up, which provided some of the same facilities: Kerberos and Cosign to (potentially) all types of services for "full" University users, but Cosign access only to web-based services for "EASE Friend" accounts.
In 2013 a development project was started to review our authentication technology. One of the drivers for this project was that the EASE infrastructure was due to be upgraded, and there was the possibility that some missing (from our point of view) functionality might be provided. In that case it might have been a reasonable option for us to drop our own authentication system and migrate all of our users and systems to use EASE authentication instead. The project has run until now (January 2015) to allow the EASE upgrade to take place and bed in, and any new features to be rolled out.
The following reasons were put forward:
(Strictly speaking the central Edinburgh Active Directory username and password, as used for the managed Windows labs and admin machines, are distinct from EASE. Usually, though, changes are synchronised between them, so that there is the appearance of unity.)
There are a number of drawbacks which would follow a migration to EASE, including:
The above points were discussed among the Computing team, and at the Computing Executive Group (minutes item 1.32), where it was concluded that the reasons for retaining our own authentication systems more than outweighed any reasons for migrating to EASE.
The project's home page contains links to working documents and meeting notes. These add technical detail to the above.