Open Stack

Added my comments in the etherpad.

----

I really think role assignment merits its own CRUD. Since there's a new API
to get the role assignments.
 
GET /role_assignments
 
why not just have the complete API set to facilitate role assignments? That
way, we have one unified API for role
assignment, as oppose to multiple APIs as exist today.

To get a role assignment:

GET /role-assignments/{role_assignment_id}

To remove a role assignment:

DELETE /role-assignments/{role_assignment_id}

To create a role assignment:

POST /role_assignments
 
{"role_assignment": {
    "user" {
        "id": user_id
    },
    "role": {
        "id": role_id
    },
    "scope": {
        "domain": {
            "id": domain_id
        },
        "project": {
            "id": project_id
        }
    }
}

Note: "user" and "scope" is similar to the data structure in auth APIs. i.e.
can be either "id" or "name" + "domain".
If assignment is for a group, just have "group" in there instead of "user".
For example,

{"role_assignment": {
    "group" {
        "id": group_id
    },
    "role": {
        "id": role_id
    },
    "scope": {
        "domain": {
            "id": domain_id
        },
        "project": {
            "id": project_id
        }
    }
}
 
Upon successful creation, a assignment_ref is returned. 
 
{"role-assignment": {
    "id": role_assignment_id
    "user": {
        "id": user_id
    },
    "role": {
        "id": role_id
    },
    "scope": {
        "domain": {
            "id": domain_id
        },
        "project": {
            "id": project_id
        }
    }
    "links": {
        "self":
"http://localhost:35357/v3/role-assignments/{role_assignment_id}"
    }
}
 
"scope" is basically the combination and permutation of domains and
projects. "domain_id" or "project_id" can be "*" to denote all.

Role assignment is really about assigning a given [role] to a given [user or
group] 
for [a given project | a given domain | all projects within a given domain |
all projects in all domains | all domains].

To assign a given role to a given user or group for [a given project]

"scope": {
    "project": {
        "id": project_id
    }
}

To assign a given role to a given user or group for [all the projects in a
given domain]

"scope": {
    "domain": {
        "id": domain_id
    },
    "project": {
        "id": "*"
    }
}

To assign a given role to a given user or group for [a given domain]

"scope": {
    "domain": {
        "id": domain_id
    }
}

To assign a given role to a given user or group for [all the projects in all
domains]

"scope": {
    "domain": {
        "id": "*"
    },
    "project": {
        "id": "*"
    }
}

To assign a given role to a given user or group for [all domains]

"scope": {
    "domain": {
        "id": "*"
    }
}


The advantages of role_assignments CRUD are:

1) simplicity (one API for role assignment, instead of multiple)
2) extensible (similiar to the auth API design). Say we need an assignment
at the federated level, we can simply add a new scope.
3) consistency (with the auth APIs)
4) RESTful (no need to worry about * in the path)



Guang

-----Original Message-----
From: Tiwari, Arvind 
Sent: Wednesday, June 12, 2013 9:29 AM
To: Henry Nash
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] More on inherited domain roles

Hi Henry,

Thanks for looking in to my comments, I was trying to raise #3 from your
list.  Any ways lets discuss this topic on etherpad from here onwards.

Thanks,
Arvind
________________________________________
From: Henry Nash [henryn at linux.vnet.ibm.com]
Sent: Wednesday, June 12, 2013 10:58 AM
To: Tiwari, Arvind
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] More on inherited domain roles

Hi

So what you have described is correct, in terms of needing multiple roles IF
you want one role that only goes to projects and one that doesn't (e.g.
maybe goes to just domains). Role explosion was the issue raised against
using the role def to hold inheritance behaviour, when it was first
discussed.  However, I'd make the following comments:

1) Most services don't need to be concerned about domains, just projects -
in fact, today, only keystone understands domains.  Hence there really won't
be a role explosion  in terms "Number of Services" x "Multiple roles due to
inheritance to projects or domains"
2) In addition, I can imagine than often a cloud provider will create  roles
that are project related separate from those that are domain related - they
tend to be different people doing those roles (e.g. user_group_admin vs
VM_admin etc.), so again, I think there won't be much of any additional role
explosion due to the inheritance rules between these roles
3) What there might be, is some role explosions between roles that go to all
domains vs roles that go to individual domains - for that, you will need
multiple roles.
4) For correctness (since we spend 40 mins on IRC on this :-) ), the
"inherited to:" field you use wasn't one of the discussed options - I agree
this is not the email to discuss that, but I don't want anyone thinking that
the structure below was one we looked at.

For all:  The options being discussed are continuing on an etherpad, see:
https://etherpad.openstack.org/keystone-role-inheritance.  This contains all
the various options being considered, including links to the previous ones
we looked at (e.g. not using the role def)

Henry
On 11 Jun 2013, at 21:18, Tiwari, Arvind wrote:

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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/f82f3ccf/attachment.bin>