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




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to