[openstack-dev] [Keystone] Feasibility of adding global restrictions at trust creation time

Nathan Kinder nkinder at redhat.com
Wed Jul 23 00:20:44 UTC 2014


Hi,

I've had a few discussions recently related to Keystone trusts with
regards to imposing restrictions on trusts at a deployment level.
Currently, the creator of a trust is able to specify the following
restrictions on the trust at creation time:

  - an expiration time for the trust
  - the number of times that the trust can be used to issue trust tokens

If an expiration time (expires_at) is not specified by the creator of
the trust, then it never expires.  Similarly, if the number of uses
(remaining_uses) is not specified by the creator of the trust, it has an
unlimited number of uses.  The important thing to note is that the
restrictions are entirely in the control of the trust creator.

There may be cases where a particular deployment wants to specify global
maximum values for these restrictions to prevent a trust from being
granted indefinitely.  For example, Keystone configuration could specify
that a trust can't be created that has >100 remaining uses or is valid
for more than 6 months.  This would certainly cause problems for some
deployments that may be relying on indefinite trusts, but it is also a
nice security control for deployments that don't want to allow something
so open-ended.

I'm wondering about the feasibility of this sort of change, particularly
from an API compatibility perspective.  An attempt to create a trust
without an expires_at value should still be considered as an attempt to
create a trust that never expires, but Keystone could return a '403
Forbidden' response if this request violates the maximum specified in
configuration (this would be similar for remaining_uses).  The semantics
of the API remain the same, but the response has the potential to be
rejected for new reasons.  Is this considered as an API change, or would
this be considered to be OK to implement in the v3 API?  The existing
API docs [1][2] don't really go to this level of detail with regards to
when exactly a 403 will be returned for trust creation, though I know of
specific cases where this response is returned for the create-trust request.

Thanks,
-NGK

[1]
http://docs.openstack.org/api/openstack-identity-service/3/content/create-trust-post-os-trusttrusts.html
[2]
http://docs.openstack.org/api/openstack-identity-service/3/content/forbidden.html



More information about the OpenStack-dev mailing list