These features would add more complexity in some security-sensitive code. Do we need this flexibility right now?

For example, the "list of allowed domains" can be enforced with mod_auth_gssapi.

I'm not that sure. I think, that second one is more important here (to limit only one principal per user). Let's leave it for discussion, if there is no serious need for this, we can drop it for now.

I did not mean to rain on the parade. The reason I care about this is that setting up Kerberos is already really difficult for new users, and I wanted to avoid adding more complexity here and increasing the QE test matrix.

Along those lines, I have an idea for writing a koji CLI plugin to bootstrap the first admin user locally so admins don't have to run the "INSERT" statements by hand, and it would be great to keep that implementation simple also.

The list of realms allowed to authenticate and realms with equivalent primaries (ie, userids) should not be assumed to be the same. The current Koji LoginCreateUser code assumes that if FOO.COM and BAR.COM establish cross-realm trust, alice@FOO.COM and alice@BAR.COM are the same person. While that may be true in some environments, that is NOT a valid general assumption, and should not be the Koji default.

One other simplification that could certainly be made to the Kerberos server code is to stop calling it Kerberos. While the client side does have some kerberos-specific code, the server side is effectively generic external web server authentication via REMOTE_USER at this point.

You're right that it uses REMOTE_USER. What would you call it instead @jforaker ?