Open Stack

I agree with dome of David's points (particularly point two about the inscrutability of the actor during impersonation), but more importantly I would like to ask that this discussion stay friendly and constructive.

This feature was discussed at tremendous length here on this mailing list and the specification underwent numerous public revisions. Short of explicitly requiring that the OpenStack Security Group sign off on features/specifications I'm not sure more could/should have been done. There's no reason these issues couldn't have been raised during the design phase, so being pejorative about it now is unnecessary.

Dolph was simply trying to make a final effort to raise awareness for those who hadn't noticed or had chosen not to pay attention to the earlier phases, and I'm glad he did since there are likely still issues that should be revisited in the H cycle.

All the best,

    - Gabriel

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Friday, March 15, 2013 10:16 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [OSSG] [keystone] Trusts: delegation and
> impersonation
> 
> Here are my comments, some of which I have made before in various
> previous emails
> 
> 1. Trusts is actually the concept of delegation, and you should remove the
> term trusts altogether and simply use the term delegation, since this is the
> well known concept and it should be sufficient to cover all the use cases you
> require.
> 
> 2. From a security perspective, impersonation (where the service cannot tell
> the difference between the real user and the imposter) should be a no-go
> area. You simply should not provide any support for it, as the system looses
> all means of auditing who did what, and the delegator has no means of
> controlling what the delegate is entitled to do. (Clearly you cannot forbid it,
> since anyone can give their authentication credentials to anyone else, but
> from the service's perspective, this is always the user who is accessing the
> resource and must take full responsibility for this, and it is not the
> impersonator). It maybe that the functionality your require is to delegate a
> user's full set of privileges, but this should still be done by delegation and not
> by impersonation, as then the system retains a full audit of who did what.
> However in the specification you set the user attribute of the delegation to
> that of the trustor instead of the trustee. This is bad, as the generated token
> is then in the name of the trustor rather than the trustee. In my opinion the
> impersonation feature should be removed as quickly as possible.
> 
> 3. A user should be able to delegate any of his authz privileges, depending
> upon the constraints of the privilege authority. So, for example, I can
> delegate my role if the role/attribute authority allows it. Otherwise I cannot. I
> dont believe you have this constraint in your model, so it is a deficiency. For
> example, whilst I might be able to delegate my role A to someone else, I
> should not be able to delegate my age or my current location (both of which
> can be authz attributes e.g.
> for age related and location related services). So the attribute authority must
> be able to control whether delegation is allowed or not, and if it is, how much
> it is (e.g. length of delegation chains). You typically can never delegate your
> driving license to anyone. So who is the attribute authority for the attributes
> that are currently being delegated in your "trusts" model, and how do they
> control this?
> 
> 4. Before you do any coding of security functionality ideally you should have a
> properly specified design that has been rigorously reviewed and agreed
> upon (and the security group of OpenStack should sign these off before
> implementation proceeds). Security is very hard to get right, and simply going
> ahead and coding something up first without a proper design and review
> phase, is in my opinion folly. (I think Keystone suffers from a number of such
> functionalities.) You will end up wasting time in the long run, due to the
> amount of bug fixing and re-factoring you will have to do, and you will also
> introduce security vulnerabilities into your system as well, due to an
> improperly specified or insufficiently reviewed design. We all know that the
> current Keystone system has a number of such "features".
> 
> In summary, I would like to improve the security of Keystone, but I think that
> an improved way of working is needed
> 
> regards
> 
> David
> 
> On 14/03/2013 18:59, Dolph Mathews wrote:
> > This is a feature that just landed in Grizzly which could certainly
> > use some extra security-focused eyes.
> >
> > There's two use cases being addressed:
> >
> > 1) Scoped role delegation with optional impersonation: "I trust user X
> > to perform role Y on project Z, optionally for some duration of time,
> > and optionally while impersonating me."
> >
> > 2) Impersonation: "I trust user X to impersonate me, optionally for
> > some duration of time."
> >
> > In short, a trust is created by a trustor; the trustee must first
> > authenticate as themselves, and then may consume the trust by
> > specifying it's ID (which is not necessarily a secret); the trustee
> > then receives a token with the project and associated roles as
> > specified by the trustor; the generated token may also reflect the
> > trustor's identity, instead of the trustees (but will contain an
> > impersonation flag to indicate this behavior).
> >
> > The original blueprint [1] outlines the goal of the feature and
> > contains links to relevant patches. The Identity API v3 specification
> > contains a fairly thorough overview of the final concept [2] along
> > with a examples for each of the related API calls [3]. The
> > implementation is mostly housed in the keystone.trust package [4]
> > although it also affects both
> > v3 and v2 auth flows, in the keystone.auth [5] and keystone.token [6]
> > packages, respectively.
> >
> > [1]: https://blueprints.launchpad.net/keystone/+spec/trusts
> >
> > [2]:
> > https://github.com/openstack/identity-api/blob/master/openstack-identi
> > ty-api/src/markdown/identity-api-v3.md#trusts
> >
> > [3]:
> > https://github.com/openstack/identity-api/blob/master/openstack-identi
> > ty-api/src/markdown/identity-api-v3.md#trusts-1
> >
> > [4]: https://github.com/openstack/keystone/tree/master/keystone/trust
> >
> > [5]: https://github.com/openstack/keystone/tree/master/keystone/auth
> >
> > [6]: https://github.com/openstack/keystone/tree/master/keystone/token
> >
> > Thanks for all your hard work, Adam!
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev