Open Stack

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 
<strong>REMOTE_USER</strong> set by the Apache web server.  
<strong>REMOTE_USER</strong> by itself is not enough to send to Keystone 
to get a token.

Kerberos has a Delegation mechanism called <a 
href="http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/" 
title="Setting Up S4U2Proxy with FreeIPA">"Service for User to Proxy" 
(abbreviated as S4U2Proxy)</a> 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 <em>all</em> 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.