This is a bit different from how I would have expected it to work. It appears that you are adding the role assignment when the project is created. IMO the role should be added to the list when the roles are checked. In other words, when getting the list of roles for a user/project, it walks up the tree to find all parent projects and creates a list of roles that includes all of the parent roles for that user that are marked inheritable. The implementation you made seems very fragile if parent projects are changed etc.
Vish On Apr 14, 2014, at 12:17 PM, Raildo Mascena <[email protected]> wrote: > Hi all, > > As I had promised, here is the repository of Telles Nobrega > (https://github.com/tellesnobrega/keystone/tree/multitenancy) updated now > with inherited roles working with hierarchical projects. > > How does it work? > > Inherited roles operate in the following way: > - It should be added a role to be inherited to a domain using the api "PUT > localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects". > - It should be created a hierarchical project as described above for Telles. > - List the assignments roles "GET localhost: 35357/v3/role_assignments" and > check that the role inherited is already associated with this new project. > > What was implemented? > The implementation consists of filtering roles which are associated with > the parent project to be inherited (this is done by checking the assigment > table) for them to be added to the child project. Also a filter has been > created to ensure that a role inherited from another domain does not > interfere in the inheritance of this project. > > What remains to implement? > > Role inheritance has been implemented to work with domains, so the role > will be inherited to all projects contained this domain, ie, a role that is > marked to be inherited, even if it is not associated with the parent project, > will be inherited to the child project. In my opinion, should be created > a "project" column in the "assignment" that would indicate where to start > inheritance projects, it would be possible to finish this feature. (This is > just a suggestion, I believe there are other ways to make it work). > > > 2014-03-17 8:04 GMT-03:00 Telles Nobrega <[email protected]>: > That is good news, I can have both information sent to nova really easy. I > just need to add a field into the token, or more than one if needed. RIght > now I send Ids, it could names just as easily and we can add a new field so > we can have both information sent. I'm not sure which is the best option for > us but i would think that sending both for now would keep the compatibility > and we could still use the names for display porpuse > > > On Sun, Mar 16, 2014 at 9:18 AM, Jay Pipes <[email protected]> wrote: > On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote: > > Awesome, this is exactly what I was thinking. I think this is really > > close to being usable on the nova side. First of all the > > dot.sperated.form looks better imo, and I think my code should still > > work that way as well. The other piece that is needed is mapping ids > > to names for display purposes. I did something like this for a > > prototype of names in dns caching that should work nicely. The > > question simply becomes how do we expose those names. I’m thinking we > > have to add an output field to the display of objects in the system > > showing the fully qualified name. We can then switch the display in > > novaclient to show names instead of ids. That way an admin listing > > all the projects in orga would see the owner as orga.projb instead of > > the id string. > > > > The other option would be to pass names instead of ids from keystone > > and store those instead. That seems simpler at first glance, it is not > > backwards compatible with the current model so it will be painful for > > providers to switch. > > -1 for "instead of". "in addition to" would have been fine, IMO. > > Best, > -jay > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > ------------------------------------------ > Telles Mota Vidal Nobrega > Bsc in Computer Science at UFCG > Software Engineer at PulsarOpenStack Project - HP/LSD-UFCG > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Raildo Mascena > Bachelor of Computer Science. > Software Engineer at Laboratory of Distributed Systems - UFCG > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
