Open Stack

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-identity-api/src/markdown/identity-api-v3.md#trusts
>
> [3]:
> https://github.com/openstack/identity-api/blob/master/openstack-identity-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
>