I’ve been looking in to enabling Kerberos for Horizon. Since Horizon passes the Users credentials on to Keystone to get a token, Kerberos requires an additional delegation mechanism. This leads to some questions about how to handle delegation in the case of Federated Identity.

In Kerberos, the Horizon Django App would get a REMOTE_USER set by the Apache web server. REMOTE_USER by itself is not enough to send to Keystone to get a token.

Kerberos has a Delegation mechanism called “Service for User to Proxy” (abbreviated as S4U2Proxy) which would allow (only) Horizon to get a service ticket to Keystone on behalf of the user. I am pretty certain we can make this work without too much effort.

The exposure of a hacked Horizon set up this way would be limited to those active service tickets in the webserver. Since Kerberos tickets are typically 8 hours in duration, the hacker would have full access to Keystone and Keystone only for any use that had logged in in the past 8 hours, or that logged in while the attack was running. Essentially, it would be the same exposure as the current Horizon model would have; both ticket duration and token duration are configurable.

If Horizon under Kerberos falls back to a user-id/password mechanism, the Horizon server could fetch a much more powerful Ticket Granting Ticket (TGT) for the user and use that to get a service ticket. The exposure for this is much greater; a successful hacker could impersonate the user to all services. Unfortunately, business requirements often demand a fallback to UserID/Password for users with limited ability to administer their own machines. mod_auth_krb5 provides a means to use userid and password, and there are form based approaches, too.

For SAML we would need a comparable delegation mechanism. If Horizon were authorized to access Keystone on the behalf of the user, and it provided the original SAML Assertion, we would have the same exposure as the S4U2Proxy case. SAML assertion are time limited, so the Hacked Horizon instance would only be able to access Keystone, and only for the duration of the SAML assertions.

In both cases, the exposure would be better than today using User-Id/Password to get tokens from Horizon in the deployments when the tokens have a default lifetime of 12 hours. Whereas as sniffed password would be usable indefinitely, a stolen assertion or service ticket would only be usable for the life of the ticket or assertion, and on so long as the Horizon service itself is still compromised.

The Keystone default token duration has been shortened to one hour, and a corresponding Service ticket policy would make sense: limit Kerberos Service tickets or SAML assertions to access Horizon to one hour.

I’m digging into X509 client certificates as well, but there does not seem to be as clear a story there. I think the short of it is “theoretically possible” but may be impractical.