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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev