On Thu, Jul 17, 2014 at 11:12 AM, Morgan Fainberg <morgan.fainb...@gmail.com > wrote:
> > > > > 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). > Thanks for the clarifications! Sounds like getting full Keystone V3 support by default is doable in Juno. > > > Cheers, > Morgan Fainberg > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
