Open Stack

On Thu, Jul 17, 2014 at 11:12 AM, Morgan Fainberg <morgan.fainberg at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140722/8e92d8e3/attachment.html>