Support for multiple Kerberos realms in GitLab is inconsistent

Hi,

GitLab is not currently consistent in how it manages Kerberos identities. For Kerberos, a principal is typically in the form username@REALM. In GitLab, the extern_uid for a Kerberos identity could be either the full username@REALM or just 'username' if we assume the realm is necessarily the system's configured default realm (which is an optional setting in krb5.conf; this value is accessible from Krb5 libraries)

#34 (closed) already points some inconsistencies in Kerberos identities generated by GitLab when using the Omniauth Kerberos provider, depending on whether LDAP is also enabled.

Commit 73c0dfd2 clearly goes in the direction of storing only the username part in the extern_uid of a Kerberos identity. (before that, the realm was stored as well)

On the other hand, !6 (merged) and !29 (merged) go in the direction of using username@REALM as the Kerberos identity, in order to support the more general case. In effect, in an environment with multiple Kerberos realms, 'username' may not be unique while 'username@REALM' is.

So this brings the question of whether GitLab wishes to support multiple Kerberos realms (for instance, multiple AD domains) or not.

If the answer is yes, then all Kerberos support code should explicitly manage identities as username@REALM (plain 'username' identities may still be supported for compatibility, but then they should be processed as if they were in the default Kerberos realm)

If such support is not considered necessary, then !6 (merged) and !29 (merged) can be simplified to store 'username' only. However, for security reasons (to prevent someone with a principal username@OTHER.REALM from being able to hijack the Gitlab account of username@DEFAULT.REALM) it seems necessary that all Kerberos authentication code always verifies that a Kerberos principal username@REALM is in the default realm before stripping the REALM part, and not strip it blindly (cf. e0d5c592 and Gitlab::Kerberos::Authentication). It may also be a good idea to document that GitLab supports only a single Kerberos realm and that a default_realm must be specified in krb5.conf (it's an optional setting)

I'm happy to submit a MR to make things consistent either way, but input from GitLab developers seems necessary at this point to clarify what direction to take.

Thanks! Alex