Pros and cons of alternatives to our existing MIT Kerberos authentication infrastructure

Note: we are really only concerned with the server-side (KDC) here. Whatever we do, DICE client-side is probably most sensibly handled through the distribution's supplied packages, as they are integrated with the rest of the distribution. We rely on the existing code for other platforms, and they seem to work well enough. However, there may be implications for some of the admin tools and PAM modules, as noted below.

Recommendations:

  1. Given the state of flux with the EASE KDCs, this would not be a good time to move all our authentication to use them.
  2. We should migrate from an MIT KDC as supplied with SL6 (current situation) to an MIT KDC built from source.
  3. We may want to consider the principle of moving to EASE now, though deferring any implementation until a later date.
  4. If we do not reject EASE on principle now, we should revisit this possibility in a couple of years once their upgrades are done and the "devolved principal mangement" is in place and we can evaluate it properly.
  5. We should continue to track Heimdal, and re-evaluate its use as appropriate.

MIT KDC as supplied with SL6 (current situation)

Pro:

Con:

MIT KDC built from source

(Only for KDCs; client side would continue to use RH packages.)

Pro:

Con:

Heimdal KDC

(Only for KDCs; client side would continue to use RH's MIT packages.)

Pro:

Con:

EASE

Note: the "EASE" that people seem to want is the cosign authentication. It's not clear that they particularly care about the underlying Kerberos technology. Indeed, IS's own what is EASE page describes it as a "web login service", and though there is some mention of Kerberos it doesn't get much prominence. That being the case, it is possible to set up cosign to speak to the EASE servers, which would then authenticate against the EASE KDCs.

The "EASE" we're considering here, then, is completely replacing our own KDCs and cosign servers with the EASE ones.

The EASE admindocs have links to a number of EASE-related topics.

Pro:

Con:

Active Directory

Everything that applies to the "EASE" section above would apply to AD (ED.AC.UK realm) even more so!

Composite approaches

  1. Use EASE for user authentication, and our own KDCs for host and service principals.
  2. Use cross-realm relationship with EASE to allow our cosign and web servers to accept EASE.ED.AC.UK factors and/or the EASE cosign servers to accept INF.ED.AC.UK factors.

$Id: ProsAndCons.html,v 1.65 2013/05/02 15:26:05 gdmr Exp $