Hi, Maybe I'm mis-understanding something here, but in the long term, when tenancy is fully implemented on all items in the system, I do not see any real issue with handling the capability to assign a role to user like any other capability. As I see it, there is a guy in the organization that have the role allowing him to add users and give roles to them. He does not have tbe capability to change ds, but I trust him to give the relevant role to the users that are allowed to do so. What is wrong with that? If this user belong to a cp, I would not like him to manipulate servers in the cdn, but it is resolved by tenancy, not capabilities. I do not care if a cp user has the capability to define a server. This user can further create a tenant specific roles and capabilities, that he can manage (unlike the builtin capabilities and roles that should be read only for everyone)
What am I missing? Nir On May 5, 2017 6:34 PM, "Jeremy Mitchell" <mitchell...@gmail.com> wrote: > @Eric - I don't think we want to take the access control granularity below > the API level. That would make things pretty messy imo and I think this new > roles/capabilities model might be enough to digest as it is. > > so basically, if you have a role that has a capability that maps to the > POST /api/version/users api endpoint (create user), then you can create > users. But of course, new users need a role. I think we should just > leverage what we have in place now - priv_level. > > So, basically, if I have the ability to create users, I can only create > users with a role that has a priv_level <= my role's priv level. > > I don't know if i want to add another hierarchy (role hierarchy)....the > less hierarchies the better :) > > Jeremy > > On Thu, May 4, 2017 at 6:39 AM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > > > Could we further differentiate the user creation capabilities to: > > - Create CDN Admin user > > - Create CDN Ops user > > - Create CDN Viewer user > > - Create Tenant Admin user > > - Create Tenant Ops user > > - Create Tenant Viewer user > > > > Then only the CDN-Admin role would have the capability to create a cdn > > admin user. Would be good to see the capabilities assigned at a > granularity > > below API endpoint in this case. > > > > As for creation of new roles, I like #2 and #3. Users should not be able > > to level-up anyone’s capabilities beyond their own. Further, capabilities > > are enforced by code, so we should not allow creation of new capabilities > > by API > > > > - - Eric > > > > > > > > On May 3, 2017, at 9:44 AM, Durfey, Ryan <ryan_dur...@comcast.com< > mailto: > > ryan_dur...@comcast.com>> wrote: > > > > Moving this active debate into the mailing list. > > -Jeremy makes a good point. We need a method for making restricting > roles > > and capabilities for lower tier staff that can create new users. Jeremy > > has suggested a point system or a hierarchy. I think either of these > would > > work if applied correctly. I am open to any approach that works. > > > > My thoughts: > > 1. We need to limit which users can build new roles from capabilities or > > new capabilities from APIs. This could be limited to a master role like > > “CDN Admin”. Otherwise other admins could circumvent the system by > > matching APIs to lower tier roles. > > 2. Another simple approach may be to only allow non-CDN Admins to assign > > roles to users which they have access. Basically you can’t give anyone > > more rights than you have. > > 3. Perhaps with this approach we allow non-CDN Admins to build roles from > > existing capabilities to which they have access, but not create > > capabilities from APIs. Then they can build new roles and assign any > > capabilities or roles to which they already have access. > > > > > > > > From: Jeremy Mitchell > > > > I like this model of a user has a role which has capabilities which map > to > > API endpoints, however, there seems to be one flaw or at least one > > unaccounted for use case. > > Let's look at the roles listed above: > > > > * CDN-Admin > > * CDN-Ops > > * CDN-Viewer > > * Tenant-Admin > > * Tenant-Ops > > * Tenant-Viewer > > > > Jeremy is a CDN-Admin which has the user-create capability (among others) > > so he creates Bob, a Tenant-Admin. Being a Tenant-Admin, Bob also has > > user-create so he creates Sally and he can give her ANY role so he > decides > > to give Sally the CDN-Admin role....whoops, we don't want that... > > Bob should be limited to creating users with role=Tenant-Admin (his > role), > > Tenant-Ops or Tenant-Viewer...but how do we correlate one role with > > another? Currently, we have "privilege level" attached to a role. So I > > guess we could use that like so: > > > > * CDN-Admin (100) > > * CDN-Ops (50) > > * CDN-Viewer (40) > > * Tenant-Admin (30) > > * Tenant-Ops (20) > > * Tenant-Viewer (10) > > > > Now, being a Tenant-Admin with the user-create capability, Bob can only > > create users where role.priv_level is 30 or below. I feel like this might > > be the easiest solution. > > Thoughts? > > > > > > ... > > Now, being a Tenant-Admin with the user-create capability, Bob can only > > create users where role.priv_level is 30 or below. I feel like this might > > be the easiest solution. > > Or...you could make roles hierarchical the way that tenants are > > hierarchical.... > > -CDN-Admin > > --CDN-Ops > > --CDN-Viewer > > --Tenant-Admin > > ---Tenant-Ops > > ---Tenant-Viewer > > And in this scenario, if you have the user-create capability you can > > create users with your role or a child of your role... > > Thoughts? > > > > > > Ryan Durfey > > Sr. Product Manager - CDN | Comcast Technology Solutions > > 1899 Wynkoop Ste. 550 | Denver, CO 8020 > > M | 303-524-5099 > > ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com> > > 24x7 CDN Support: 866-405-2993 or cdn_supp...@comcast.com<mailto: > > cdn_supp...@comcast.com> > > > > > > >
