Should we migrate our existing authentication to use EASE instead?

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.

Why might we have wanted to migrate to EASE?

The following reasons were put forward:

  1. It was suggested that it would be simpler and less confusing for users to have only one "Edinburgh" password to authenticate them to Informatics and other Edinburgh systems. This applies primarily to first- and second-year undergraduates, as most of our other students use mainly Informatics systems. Staff have additional non-EASE passwords and usernames to manage, in any case, including for eduroam (wireless), financial systems, and E&B systems.

    (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.)

  2. It would be useful to be able to authenticate web pages against EASE Cosign rather than our own Informatics Cosign. (This is actually straightforward to do on a per-site basis, and we have several sites set up in this way. For example: the DICE password portal; the Informatics Discussion Forum.)
  3. The University prefers that Schools not duplicate central provision, unless there is a good reason to do so, as duplication is perceived to result in additional effort overall.

Why might we not want to migrate to EASE?

There are a number of drawbacks which would follow a migration to EASE, including:

  1. Our iFriend users would have to migrate to the University's central EASE Friend system. Unfortunately this is Cosign-only, which would mean that subversion, ColTeX and AFS would no longer be available to them.
  2. It would be considerably harder to maintain "Informatics-only" content, as we would no longer be able to authorize on the basis of Informatics-specific authentication.
  3. There would be some considerable cost and disruption caused in making the transition.
  4. We would lose control over user accounts and passwords, as these would be created and managed centrally. Specifically this would seriously impact on
  5. It introduces outside dependencies, which could render Informatics systems unusable. As things stand now, we could lose all our outside connectivity and Informatics users would still be able to continue to work reasonably normally. Migration to EASE would mean that any problems with EdLAN or EASE could prevent Informatics users from working at all.
  6. We would be subject to policies outwith our control, which might detrimentally affect user, host and service principals. The EASE administrators might well not even realise that has happened.
  7. We do share code and expertise with the EASE team, to the benefit of both. The EASE KDCs are on lcfg-managed Linux machines, as are ours.
  8. Overall the additional support costs involved in interacting with IS would more than outweigh the small cost involved in running our own Informatics and iFriend authentication systems.
  9. We would lose the ability to innovate in the methods of authentication we could support.

Conclusion

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.