You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Durfey, Ryan" <Ry...@comcast.com> on 2017/05/03 13:44:39 UTC
Access Control - Limiting Roles / Capabilities Tenant Admins can
Assign to Users
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.
[cid:image001.png@01D2C3E1.1DF8D3B0]
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_durfey@comcast.com<ma...@comcast.com>
24x7 CDN Support: 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>
Re: Access Control - Limiting Roles / Capabilities Tenant Admins can
Assign to Users
Posted by Jeremy Mitchell <mi...@gmail.com>.
@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 <ni...@qwilt.com> 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" <mi...@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) <
> > efriedri@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_Durfey@comcast.com<
> > mailto:
> > > Ryan_Durfey@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_durfey@comcast.com<ma...@comcast.com>
> > > 24x7 CDN Support: 866-405-2993 or cdn_support@comcast.com<mailto:
> > > cdn_support@comcast.com>
> > >
> > >
> > >
> >
>
Re: Access Control - Limiting Roles / Capabilities Tenant Admins can
Assign to Users
Posted by Nir Sopher <ni...@qwilt.com>.
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" <mi...@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) <
> efriedri@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_Durfey@comcast.com<
> mailto:
> > Ryan_Durfey@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_durfey@comcast.com<ma...@comcast.com>
> > 24x7 CDN Support: 866-405-2993 or cdn_support@comcast.com<mailto:
> > cdn_support@comcast.com>
> >
> >
> >
>
Re: Access Control - Limiting Roles / Capabilities Tenant Admins can
Assign to Users
Posted by Jeremy Mitchell <mi...@gmail.com>.
@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) <
efriedri@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_Durfey@comcast.com<mailto:
> Ryan_Durfey@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_durfey@comcast.com<ma...@comcast.com>
> 24x7 CDN Support: 866-405-2993 or cdn_support@comcast.com<mailto:
> cdn_support@comcast.com>
>
>
>
Re: Access Control - Limiting Roles / Capabilities Tenant Admins can
Assign to Users
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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 <Ry...@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_durfey@comcast.com<ma...@comcast.com>
24x7 CDN Support: 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>