Open Stack

Hi All,

Role inheritance is very cool feature and we need this in product, but letting RoleDef to drive the inheritance behavior seem wrong to me as it will cause roleDef explosion and complex policy for services to support.

Let's assume a requirement


1.       Cloud admin should have XYZ capability on all the projects, all domains for Sev1. (Global inheritance)

2.       Domain admin should have XYZ capability only on the projects in specific domain for Sev1. (inheritance scoped to a domain)


With the current approach (having inherited to in roleDef) we have to have following two roleDefs to support the requirement and hence you have to adjust the policy around these two roleDefs but end result is XYZ capability.
{
    "role": {
        "id": "---id---",
        "inheritedTo": "domain=all and project=all", (This means, holder of this role has XYZ capability in all projects in all domains) (Lets not worry about the how we implement it enum / Boolean flag)
        "links": {
            "self": "http://identity:35357/v3/roles/76e72a"
        },
        "name": "XYZ-Role-4-cloud-admin"
    }
}

{
    "role": {
        "id": "---id---",
        "inheritedTo": "project=all", (This means, holder of this role has XYZ capability in all projects in specific domain)
        "links": {
            "self": "http://identity:35357/v3/roles/76e72a"
        },
        "name": " XYZ-Role-4-domain-admin "
    }
}

Think about growing number of service and above mentioned requirement, we will end up with so many  roleDefs which will have duplicate capability and hence redundant info to maintain in policy. At the same time this solution does not address separation of concerns, we are unnecessary overloading the roleDefs to impose role inheritance behavior which is not its concern. The above mentioned requirement can be easily achievable by single roleDef (may be XYZ-role-Svc1) if we remove inheritedTo concern from roleDef and place it some ware else, role assignment is the right place to address this concern, how that we need to figure out.

Let me know if the issue I mentioned looks legitimate.



Thanks,
Arvind

From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
Sent: Monday, June 10, 2013 4:30 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [keystone] More on inherited domain roles

Hi

So I ave submitted two new api reviews around this:

1) Defining inherited roles - this is now done on the role def itself, as suggested by David. See: https://review.openstack.org/#/c/29781/12
2) The two un-implmented user/role apis have been replaces with a more flexible way of listing role-assignments. See:https://review.openstack.org/#/c/32394/2

I'd like to push to get this nailed asap, so we can have a  shot at getting the code in!

Both of these extensions are designed to give us the option to to expand this support for inheritance to all domains in the future if we chose.

Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130611/e6a8208c/attachment.html>