Re: Traffic Ops Access Control v2

[Jeremy Mitchell]

Dave,

1. Yes, the "proposed" roles are default roles that will be seeded with TO.
The idea is that you can use those roles or create your own.

2. Really, there should be no need to CRUD capabilities. for example, the
ds-read capability should always include the GET /api/deliveryservices and
GET /api/deliveryservices/:id routes. However, we do have the concept of
API extensions. For example, let's say Comcast has some extra routes (GET
/api/foos and GET /api/foos/:id). In that case, Comcast would need to
create a foos-read capability. So maybe CRUDing capabilities makes sense.
Not sure yet TBH.

3. Yes, the Admin role will be seeded to include ALL capabilities. The Ops
role will be seeded with whatever capabilities we deem appropriate. There
will probably need to be some discussion here about which capabilities the
Ops role gets. Actually, there will have to be discussion about which
capabilities each role gets. I will probably make a proposal and then get
feedback.

Jeremy

On Mon, Mar 12, 2018 at 1:02 PM, Dave Neuman  wrote:

> This sounds great Jeremy, looking forward to it getting implemented.  A few
> things though:
>
> 1) The "proposed roles" are really just "default roles" right?  Meaning we
> will provide a way to create new roles and assign capabilities to them?
> 2) We will provide a way to CRUD capabilities, correct?
> 3) Is it assumed that Admin gets everything?  What does Operations NOT get
> that admin DOES get?  Trying to differentiate between the two.
>
> Thanks,
> Dave
>
> On Thu, Mar 8, 2018 at 9:53 AM, Jeremy Mitchell 
> wrote:
>
> > There has been some discussion for quite some time regarding an overhaul
> of
> > the TO access control model. I'd like to refresh eveyone's memory on that
> > discussion.
> >
> >
> > *Current system:*
> >
> > Since the beginning, resources (or routes (UI and API)) have been locked
> > down by role, or more specifically, privilege level. For example, if a
> > route requires a privilege level of 20, then only users with the
> operations
> > role (priv level=20) or admin role (priv level=30) could access that
> route.
> > Here are our current roles (and their priv levels):
> >
> > Admin (30)
> > Operations (20)
> > Portal (15)
> > Federation (15)
> > Steering (15)
> > ORT (11)
> > Read-Only (10)
> > Disallowed (0)
> >
> > This method has served us well for quite a while but there are some
> > drawbacks to this approach. Here are a few I can think of:
> >
> > - No clear understanding of which routes each role provides access to.
> For
> > example, what is the difference between the Admin and Operations role?
> All
> > I know is that the admin role has a priv level of 30 and operations has
> 20.
> > I can't tell you which routes an admin has access to that operations does
> > not without reading the code or going thru all the docs. Ain't nobody got
> > time for that!
> >
> > - The "Additive" nature of the roles (via priv level) prevents the
> ability
> > to create unrelated roles. You can't create 2 roles with unique access.
> > Higher level roles always inherit from lower level roles. The Federation
> > role is a good example. Federation users only need access to a couple
> > routes yet since it has a priv-level=15, federation users look like they
> > can do federation, steering, portal, ort and read-only things...
> >
> > - Not easy to alter the access level of a role. For example, if you
> wanted
> > the Portal role to have access to a few more routes, what would you do?
> > Raise priv level to 18? Not sure what that would do...if anything. You'd
> > have to make code changes to ensure an 18 would actually do something.
> >
> > - Many API consumers have elevated permissions when they only need access
> > to a few routes. I.e. traffic monitors, traffic routers, traffic stats
> all
> > have to be given the admin role. so basically, they've been granted
> access
> > to do EVERYTHING when they only access a few routes.
> >
> > - There is also inconsistency in how roles are enforced. Most routes use
> > priv level to determine access but some routes simply check if the user
> has
> > the role (i.e. steering).
> >
> >
> > *New proposed system:*
> >
> > *Tenancy*
> >
> > Last summer tenancy was introduced (thanks Qwilt) giving us the ability
> to
> > "scope" certain resources (delivery services, users and also tenants) to
> > certain users. This was a big step towards self-service as we can now
> limit
> > what certain users see. Access control is now role + tenancy (if tenancy
> is
> > applicable and turned on via the use_tenancy parameter).
> >
> > *Roles/Capabilities*
> >
> > Actually, a lot of work has already been done (thanks again, Qwilt) in
> this
> > area but of course, there is more to do. Let me explain a bit how it
> works
> > conceptually.
> >
> > Proposed Roles:
> >
> > Admin
> > Operations
> > Content Provider (formerly known as Portal)
> > Federation
> > Cache (formerly known as ORT)
> > Monitor (new)
> > 

Re: Traffic Ops Access Control v2

[Dave Neuman]

This sounds great Jeremy, looking forward to it getting implemented.  A few
things though:

1) The "proposed roles" are really just "default roles" right?  Meaning we
will provide a way to create new roles and assign capabilities to them?
2) We will provide a way to CRUD capabilities, correct?
3) Is it assumed that Admin gets everything?  What does Operations NOT get
that admin DOES get?  Trying to differentiate between the two.

Thanks,
Dave

On Thu, Mar 8, 2018 at 9:53 AM, Jeremy Mitchell 
wrote:

> There has been some discussion for quite some time regarding an overhaul of
> the TO access control model. I'd like to refresh eveyone's memory on that
> discussion.
>
>
> *Current system:*
>
> Since the beginning, resources (or routes (UI and API)) have been locked
> down by role, or more specifically, privilege level. For example, if a
> route requires a privilege level of 20, then only users with the operations
> role (priv level=20) or admin role (priv level=30) could access that route.
> Here are our current roles (and their priv levels):
>
> Admin (30)
> Operations (20)
> Portal (15)
> Federation (15)
> Steering (15)
> ORT (11)
> Read-Only (10)
> Disallowed (0)
>
> This method has served us well for quite a while but there are some
> drawbacks to this approach. Here are a few I can think of:
>
> - No clear understanding of which routes each role provides access to. For
> example, what is the difference between the Admin and Operations role? All
> I know is that the admin role has a priv level of 30 and operations has 20.
> I can't tell you which routes an admin has access to that operations does
> not without reading the code or going thru all the docs. Ain't nobody got
> time for that!
>
> - The "Additive" nature of the roles (via priv level) prevents the ability
> to create unrelated roles. You can't create 2 roles with unique access.
> Higher level roles always inherit from lower level roles. The Federation
> role is a good example. Federation users only need access to a couple
> routes yet since it has a priv-level=15, federation users look like they
> can do federation, steering, portal, ort and read-only things...
>
> - Not easy to alter the access level of a role. For example, if you wanted
> the Portal role to have access to a few more routes, what would you do?
> Raise priv level to 18? Not sure what that would do...if anything. You'd
> have to make code changes to ensure an 18 would actually do something.
>
> - Many API consumers have elevated permissions when they only need access
> to a few routes. I.e. traffic monitors, traffic routers, traffic stats all
> have to be given the admin role. so basically, they've been granted access
> to do EVERYTHING when they only access a few routes.
>
> - There is also inconsistency in how roles are enforced. Most routes use
> priv level to determine access but some routes simply check if the user has
> the role (i.e. steering).
>
>
> *New proposed system:*
>
> *Tenancy*
>
> Last summer tenancy was introduced (thanks Qwilt) giving us the ability to
> "scope" certain resources (delivery services, users and also tenants) to
> certain users. This was a big step towards self-service as we can now limit
> what certain users see. Access control is now role + tenancy (if tenancy is
> applicable and turned on via the use_tenancy parameter).
>
> *Roles/Capabilities*
>
> Actually, a lot of work has already been done (thanks again, Qwilt) in this
> area but of course, there is more to do. Let me explain a bit how it works
> conceptually.
>
> Proposed Roles:
>
> Admin
> Operations
> Content Provider (formerly known as Portal)
> Federation
> Cache (formerly known as ORT)
> Monitor (new)
> Router (new)
> Stats (new)
> Read-Only
> Disallowed
>
> Concept:
>
> - a user has one role
> - a role has N capabilities (i.e. ds-read, ds-write, etc)
> - a capability is mapped to N API endpoints (i.e. ds-read is mapped to GET
> /api/deliveryservices and GET /api/deliveryservices/:id)
>
> A user's capabilities (and not privilege level) determine whether a user
> has access to an API endpoint or not.
>
> Advantages:
>
> - By mapping roles to capabilities and capabilities to API endpoints, it's
> easy to see what level of API access each role provides. For example, easy
> to see the difference between the Admin and Operations role.
>
> - Roles are not "additive". Unrelated, unique roles can be created. For
> example, the Federation role and Content Provider role (formerly Portal
> role) can provide 2 completely different levels of access control.
> Currently, they provide the exact same level of access because of priv
> level.
>
> - Tightly defined roles with specific capabilities provides better
> security. I.e. you don't have to give a user an admin role so they can do
> only 2 things.
>
> - Can create custom roles on the fly to only include access to certain API
> endpoints. If you want to create a Bob role with just the ds-read
> capability, go for it. You 

Traffic Ops Access Control v2

[Jeremy Mitchell]

There has been some discussion for quite some time regarding an overhaul of
the TO access control model. I'd like to refresh eveyone's memory on that
discussion.


*Current system:*

Since the beginning, resources (or routes (UI and API)) have been locked
down by role, or more specifically, privilege level. For example, if a
route requires a privilege level of 20, then only users with the operations
role (priv level=20) or admin role (priv level=30) could access that route.
Here are our current roles (and their priv levels):

Admin (30)
Operations (20)
Portal (15)
Federation (15)
Steering (15)
ORT (11)
Read-Only (10)
Disallowed (0)

This method has served us well for quite a while but there are some
drawbacks to this approach. Here are a few I can think of:

- No clear understanding of which routes each role provides access to. For
example, what is the difference between the Admin and Operations role? All
I know is that the admin role has a priv level of 30 and operations has 20.
I can't tell you which routes an admin has access to that operations does
not without reading the code or going thru all the docs. Ain't nobody got
time for that!

- The "Additive" nature of the roles (via priv level) prevents the ability
to create unrelated roles. You can't create 2 roles with unique access.
Higher level roles always inherit from lower level roles. The Federation
role is a good example. Federation users only need access to a couple
routes yet since it has a priv-level=15, federation users look like they
can do federation, steering, portal, ort and read-only things...

- Not easy to alter the access level of a role. For example, if you wanted
the Portal role to have access to a few more routes, what would you do?
Raise priv level to 18? Not sure what that would do...if anything. You'd
have to make code changes to ensure an 18 would actually do something.

- Many API consumers have elevated permissions when they only need access
to a few routes. I.e. traffic monitors, traffic routers, traffic stats all
have to be given the admin role. so basically, they've been granted access
to do EVERYTHING when they only access a few routes.

- There is also inconsistency in how roles are enforced. Most routes use
priv level to determine access but some routes simply check if the user has
the role (i.e. steering).


*New proposed system:*

*Tenancy*

Last summer tenancy was introduced (thanks Qwilt) giving us the ability to
"scope" certain resources (delivery services, users and also tenants) to
certain users. This was a big step towards self-service as we can now limit
what certain users see. Access control is now role + tenancy (if tenancy is
applicable and turned on via the use_tenancy parameter).

*Roles/Capabilities*

Actually, a lot of work has already been done (thanks again, Qwilt) in this
area but of course, there is more to do. Let me explain a bit how it works
conceptually.

Proposed Roles:

Admin
Operations
Content Provider (formerly known as Portal)
Federation
Cache (formerly known as ORT)
Monitor (new)
Router (new)
Stats (new)
Read-Only
Disallowed

Concept:

- a user has one role
- a role has N capabilities (i.e. ds-read, ds-write, etc)
- a capability is mapped to N API endpoints (i.e. ds-read is mapped to GET
/api/deliveryservices and GET /api/deliveryservices/:id)

A user's capabilities (and not privilege level) determine whether a user
has access to an API endpoint or not.

Advantages:

- By mapping roles to capabilities and capabilities to API endpoints, it's
easy to see what level of API access each role provides. For example, easy
to see the difference between the Admin and Operations role.

- Roles are not "additive". Unrelated, unique roles can be created. For
example, the Federation role and Content Provider role (formerly Portal
role) can provide 2 completely different levels of access control.
Currently, they provide the exact same level of access because of priv
level.

- Tightly defined roles with specific capabilities provides better
security. I.e. you don't have to give a user an admin role so they can do
only 2 things.

- Can create custom roles on the fly to only include access to certain API
endpoints. If you want to create a Bob role with just the ds-read
capability, go for it. You can get very creative with your roles if you
want to. Or you can just use those that are provided.

Disadvantages:

- More setup required. All API endpoints need to be grouped into
capabilities (again, Qwilt did a lot of work in this area). Capabilities
need to be added to the appropriate roles.

If you haven't read enough at this point and are thirsty for more. There is
more here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910

Thanks for reading. Looking forward to your comments/concerns.

Jeremy