Comment 5 for bug 1476264

In order for the other projects to handle bug bug 968696 in a consistant manner, they need support for Keystone. The alternative is that each project has policy which can work on a project other than the one scoped to the resource. While this is acceptable for things that have no inherant scoping (administrative items at the super level) tokens which are meant for those operations should not be able to affect change in individual tenants projects; any one admin token stolen can than be used for any operation through out the cluster.

There are alternatives to "bringing a project back to life: such as making it possible to perform these actions via a separate endpoint that does not accept tokens and authenticated by strong crypto, like the X509 tokenless auth patch submitted for Keystone.

Probably the most significant aspect of this patch is that, once deleted, there is no differentiator for who can create a project with an ID specified and who has to use the existing mechanism. I would probably recommend that "with id" is reserved for a more specialized class of users. Those should have a different, more stringent, policy check; either in the API call, or a whole separate API to re-cerate a proejct.

Another alternative is to "soft delete" only a project, and maintain a record. An admin could then "re-animate" a project or even get tokens scoped to a deleted project in order to delete remote resources.