@Nir - I think this is unrelated to tenancy. Tenancy controls the scope of what you can see...Roles/capabilities control what you can do.
Imagine these are the roles in the system. I renamed them to avoid confusion: (CP stands for content provider) * CDN-Admin <-- this has 100 capabilities including user-create * CDN-Ops <-- this has 80 capabilities * CDN-Viewer <-- this has 50 capabilities * CP-Admin <-- this has 30 capabilities including user-create * CP-Ops <-- this has 20 capabilities * CP-Viewer <-- this has 10 capabilities I am a user with the CP-Admin role so i can create users. Are you saying that I should be able to create users and give them any role I please. You're going to trust me? In my opinion, I should really only be creating users with role = CP-Admin, CP-Ops, CP-Viewer... Also, to your last point, Nir, and Durfey touched on this too. "This user can further create a tenant specific roles and capabilities". I don't agree. I think the ONLY role that can create,update,delete roles is the CDN-Admin. Otherwise, this will get way out of hand and you'll have people creating roles to circumvent the system. Jeremy On Fri, May 5, 2017 at 10:00 AM, Nir Sopher <[email protected]> wrote: > 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" <[email protected]> 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) < > > [email protected]> 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 <[email protected]< > > mailto: > > > [email protected]>> 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 > > > [email protected]<mailto:[email protected]> > > > 24x7 CDN Support: 866-405-2993 or [email protected]<mailto: > > > [email protected]> > > > > > > > > > > > >
