Open Stack

Hi Adam,

I would like to request you to revisit the below link and provide your opinion, so that we can move forward and try to find a common ground where everyone.

https://review.openstack.org/#/c/61897


Below is my justification for service_id in role model:
In a public cloud deployment model, service teams (or service deployers) defines the roles along with other artifacts (service and endpoint) and they need full control on these artifacts including roles. This way they can control the life cycle of these artifacts without depending on IAM service providers. (more details in https://blueprints.launchpad.net/keystone/+spec/name-spaced-roles)
As an IAM service provider in a public cloud deployment, it is our responsibility to facilitate them so that they can control full life cycle of their service specific artifacts. To make it happen we need tight access control on these artifacts, so that a service deployer accidently or maliciously not able to mess-up with other services.
To achieve that level fine granularity and to isolate service deployers from artifacts, we need to associate entity models (service, endpoints and roles) with a service.  This way we can define entity ownership and define access control policy based on service. Currently, role data model  does not support any association and that is why I am requesting  to introduce some way to associate a role with domain, project and service. This association also helps to define a namespace for making the role name globally unique.

Previously I was trying achieve tight linking of roles with service_id and that might be offending for some community members. Now after much effort and help from David Chadwick, we have generalized the role model and come up with generic design, so that it can fit in with every once use case. As I mentioned in the spec it will be backward compatible so that it won't break the existing deployments

I would appreciate if you can revisit the link and provide comments and suggestions, there might be still some room for improvements and I am open for them.


Dolph, I would also like you to review the specs, so that we can make some progress.


Regards,
Arvind




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/6a0e6198/attachment.html>