FASJSON will not authenticate on the new single-vm-for-auth scheme

[abompard]

This is a tracker bug to list what went wrong with the attempt to merge all the auth-related VMs into one (c2ed51d) to save RAM.

• It's unsupported on the IPA side to run anything else in the same VM.
• Indeed fasjson could not authenticate with Kerberos.
• Using a kerberos service named FASJSON/<hostname> will not work, because as a convention curl and other HTTP clients will request the HTTP/<hostname> principal
• Running it in a separate virtualhost solves the kerberos principal issue (same HTTP service name but different hostname), but then gssproxy can't identify the request as being directed at its fasjson service, because there's no way to have separate gssproxy sockets in the same Apache process (the selection is done via an environment variable, GSSPROXY_SOCKET).
• It is possible to run the WSGI app as a different user to route requests to gssproxy based on process user id, but the authentication is done via mod_auth_gssapi which happens long before communication with mod_wsgi.
• It is possible to use mpm-itk to run the entire virtualhost as a different system user, but it means adjusting permissions of /run/httpd, and running apache with the mod_mpm_prefork model, and I am of the opinion that doing that we'd be a bit too disruptive of the normal functionning of IPA. Also, we'd need to maintain the httpd-itk package that is orphaned in Fedora.
• The same thing would have to be done to Ipsilon.

References:

• question on the freeipa-users ML
• issue on mod_auth_gssapi

Next step: split FreeIPA in its own VM, and run noggin, FASJSON and Ipsilon on the same VM without using gssproxy.