[openstack-dev] [OSSG] [keystone] Trusts: delegation and impersonation
David Chadwick
d.w.chadwick at kent.ac.uk
Fri Mar 15 17:16:14 UTC 2013
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
>
More information about the OpenStack-dev
mailing list