Open Stack

On 07/17/2012 05:22 PM, Adam Young wrote:
> For Kerberos, I would suggest the following:
>
> 1.  Run Keystone in Apache HTTP with mod_auth_kerberos.  It can fall 
> back to userID/password.
> 2.  Modify the authentication mechanisms so that it checks REMOTE_USER 
> the same way it currently checks USERID/password when providing a token
>
> Cross realm trust is a nice-to-have,  but I suspect that it is not up 
> to Keystone to implement, but rather something that needs to be set up 
> correctly Kerberos wise.  Once Kerberos Auth works, cross realm should 
> work, too.
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
As far as using the Kerberos ticket in place of the Keystone tokens, the 
issue is that the other services (Glance, Nova etc) are running in 
eventlet as well, and thus Kerberos support would need to be ported 
upstream.  This is non-trivial, as the Kerberos API is native, which 
means the GIL will kick in.  (Reimplementing Kerberos in Python is not a 
viable option).  The GIL might not be a show stopper, but I wouldn't 
want to count on it. It does mean some native extension would be needed, 
though.  I am just not sure it is worth putting the effort into that.

If all of the service can be run in Apache HTTPD,  you could, in theory, 
replace the auth_token middleware with a new middleware 
auth_service_ticket, that again would just check for the REMOTE_USER 
value.  You would still need to make a call back to Keystone in order to 
get Tenant/Project info.  in addition,  you could not pass on the 
service ticket the way that you do the tokens, so Horizon talking to  
Nova and Glance would not work without something like TGT forwarding, 
which I don't think we would want to do, either.  So I think, shortish 
term,  using the Kerberos credentials to get the Token is still the 
right approach.  I'd be interesting in  hearing a counter argument.