Open Stack

> > I wasn't aware that PKI tokens had domains in them. What happens to nova
> > in this case, It just works?
> >
>  
> Both PKI and UUID responses from v3 contain:
>  
> 1. the user's domain
>  
> And if it's a project scoped token:
>  
> 2. the project's domain
>  
> Or if it's a domain-scoped token:
>  
> 3. a domain scope
>  
> The answer to your question is that if nova receives a project-scoped token
> (1 & 2), it doesn't need to be domain-aware: project ID's are globally
> unique and nova doesn't need to know about project-domain relationships.
>  
> If nova receives a domain-scoped token (1 & 3), the policy layer can balk
> with an HTTP 401 because there's no project in scope, and it's not
> domain-aware. From nova's perspective, this is identical to the scenario
> where the policy layer returns an HTTP 401 because nova was presented with
> an unscoped token (1 only) from keystone.

Let me add some specifics based upon the IRC discussion I had with Joe Gordon.

In addition to what Dolph has outlined here we have this document http://docs.openstack.org/developer/keystone/http-api.html#how-do-i-migrate-from-v2-0-to-v3 that should help with what is needed to do the conversion. The change to use v3 largely relies on a deployer enabling the V3 API in Keystone.

By and large, the change is all in the middleware. The middleware will handle either token, so it really comes down to when a V3 token is requested by the end user and subsequently used to interact with the various OpenStack services. This part requires no change on Nova (or any other services) part (with exception to the Domain-Scoped tokens outlined above and the needed changes to policy if those are to be supported).

Each of the client libraries will need to be updated to utilize the V3 API. This has been in process for a while (you’ve seen the code from Jamie Lennox and Guang Yee) and is mostly supported by converting each of the libraries to utilize the Session object from keystoneclient instead of the many various implementations to talk to auth.

Last but not least here are a couple bullet points that make V3 much better than the V2 Keystone API (all the details of what V3 brings to the table can be found here: https://github.com/openstack/identity-api/tree/master/v3/src/markdown ). A lot of these benefits are operator specific.

* Federated Identity. V3 Keystone supports the use of SAML (via shibboleth) from a number of sources as a form of Identity (instead of having to keep the users all within Keystone’s Identity backend). The federation support relies heavily upon the domain constructs in Keystone (which are part of V3). There is work to expand the support beyond SAML (including a proposal to support keystone-to-keystone federation).

* Pluggable Auth. V3 Keystone supports pluggable authentication mechanisms (a light weight module that can authenticate the user), this is a bit more friendly than needing to subclass the entire Identity backend with a  bunch of conditional logic. Plugins are configured via the Keystone configuration file.

* Better admin-scoping support. Domains allow us to better handle “admin” vs “non-admin” and limit bleeding those roles across projects (a big complaint in v2: you were either an admin or not an admin globally). Due to backwards compatibility requirements, we have largely left this as it was, but the support is there and can be seen via the policy.v3cloudsample.json file provided in the Keystone tree.

* The hierarchical multi tenancy work is being done against the V3 Keystone API. This is again related to the domain construct and support. This will likely require changes to more than just Keystone to make full use of the new functionality, but specifics are still up in the air as this is under active development.

These are just some of benefits of V3, there are a lot of improvements over V2 that are not on this list (or are truly transparent to the end-user and deployer).


Cheers,
Morgan Fainberg