although it may appear that roles/capabilities is more complex than the
current system (roles/priv_level), i actually think it's a lot easier from
a user perspective. let me explain.
can you tell me the difference between the operations role (priv level=20)
and the portal role (priv level=15). me neither without perusing the
codebase and/or api documentation. ain't nobody got time for that...
in the roles/capabilities world you will be able to see (in TP) that the
operations role maps to 10 capabilities (for example) and the portal role
maps to 5 capabilities (for example). this allows users to make better
decisions about who gets what role. you can even create ad-hoc roles with
the capabilities you need (assuming you have the roles-write capability of
course).
using a migration, we will do our best to provide the capabilities for each
role that simulates the current priv_level of the role to prevent any
change of behavior for a user.
regarding a clean install, i envision that only 2 roles will be provided
out of the box: admin (all capabilities), disallowed (no capabilities). it
will be up to you to define additional roles based on your needs.
and yes, rob, people will be forced to "think about and learn
roles/capabilities" but is that a bad thing? if you are creating users, you
should have an idea of what capabilities you are giving to them.
jeremy
On Mon, Jun 18, 2018 at 10:11 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:
> >when roles/capabilities are introduced our roles will look like this:
> >
> >admin (all capabilities)
> >operations (the capabilities required to at a minimum to reproduce current
> >access level of priv level=20. capabilities yet to be determined)
>
> That's essentially what I was asking. As long as we can emulate something
> similar to the "priv level" system, with both a migration and a default on
> clean install, that requires minimal effort and minimal learning curve for
> people who don't want or need a complex permission system.
>
> My biggest concern is the learning curve. For people who don't care about
> perms, can they ignore everything, use the default roles, and have object
> creation default to something that lets them do everything they need to
> ("admin")? Or are the GUI and API controls such that people are forced to
> think about and learn roles/capabilities, just to keep using the system?
>
>
>
> On Mon, Jun 18, 2018 at 9:59 AM, Rawlin Peters <rawlin.pet...@gmail.com>
> wrote:
>
> > I also agree with requiring tenancy and roles/capabilities in 3.0. In
> > fact, Traffic Portal already requires a tenant to be selected today,
> > regardless of whether or not use_tenancy is true.
> >
> > We should try to balance usability with ease of development, and we
> > could easily provide a DB migration that sets all the tenant-able
> > things to the root tenant if use_tenancy is false. But we may need to
> > draw the line and require that before the upgrade tenancy is either
> > completely fulfilled (everything is assigned to a tenant and
> > use_tenancy is true) or everything will be set to the root tenant.
> > Having been in tenancy code in the golang TO API recently, I could
> > definitely see this requirement simplifying the API quite a bit.
> >
> > As far as roles/capabilities go, we already require users to have a
> > priv_level, so I don't see requiring roles/capabilities as that much
> > of a burden. I'm not as up to speed with the development of that, but
> > I imagine we could set up a DB migration for that as well and include
> > a default set of roles/capabilities that would at least keep the
> > software as easy to use as it is today.
> >
> > - Rawlin
> >
> > On Sat, Jun 16, 2018 at 9:18 PM, Dave Neuman <neu...@apache.org> wrote:
> > > I'll admit I am not super close to this problem so I don't understand
> it
> > > well but, from what I have read, I tend to agree with Jeremy. If we
> are
> > > going to have roles/capabilities we need to just incorporate them into
> > the
> > > system and be done with it. We should have able to provide reasonable
> > > defaults and reasonable ways for people to do things that makes it
> > tenable.
> > >
> > > On Fri, Jun 15, 2018 at 9:45 AM Jeremy Mitchell <mitchell...@gmail.com
> >
> > > wrote:
> > >
> > >> regarding tenancy:
> > >>
> > >> @Nir is right. If you don't feel like using tenancy, then you give all
> > your
> > >> users tenant=root. so tenancy is easy to sidestep if you're not
> > interested
> > >> in using it.
> > >>
> > >> regarding roles:
> > >>
> > >> here are our current roles:
> > >>
> > >> admin (priv level=30)
> > >> operations (20)
> > >> portal (15) <-- terrible name for a role btw. probably my fault
> > >> federation (15)
> > >> steering (15)
> > >> ort (11)
> > >> read-only (10)
> > >> disallowed (0)
> > >>
> > >> ^^ in this world, it is your role's priv level that determines what
> you
> > >> can/cannot access
> > >>
> > >> when roles/capabilities are introduced our roles will look like this:
> > >>
> > >> admin (all capabilities)
> > >> operations (the capabilities required to at a minimum to reproduce
> > current
> > >> access level of priv level=20. capabilities yet to be determined)
> > >> portal (the capabilities required to at a minimum to reproduce current
> > >> access level of priv level=15. capabilities yet to be determined)
> > >> federation (the capabilities required to at a minimum to reproduce
> > current
> > >> access level of priv level=15. capabilities yet to be determined)
> > >> steering (the capabilities required to at a minimum to reproduce
> current
> > >> access level of priv level=15. capabilities yet to be determined)
> > >> ort (the capabilities required to at a minimum to reproduce current
> > access
> > >> level of priv level=11. capabilities yet to be determined)
> > >> read-only (the capabilities required to at a minimum to reproduce
> > current
> > >> access level of priv level=10. capabilities yet to be determined)
> > >> disallowed (no capabilities)
> > >>
> > >> ^^ in this world, it is your role's capabilities that determine what
> you
> > >> can/cannot access. if you're not interested in a "complex permissions
> > >> framework" as @Rob calls it :) , you really have to do nothing and the
> > >> access level of your users should not change (assuming we define the
> > proper
> > >> capabilities for each role).
> > >>
> > >> sooo...if in TC 3.0, we make both (tenancy and roles/capabilities) an
> > >> integral part of the system we can, like rob said, simplify a bunch of
> > >> code. it's hard enough to explain access control/permissions to
> people.
> > >> having to explain 2 ways is almost impossible imo :)
> > >>
> > >> and yes, @Rob shims could be added to TP and/or the TO API to handle
> > both
> > >> ways but again, more complexity=more bugs, etc. IMO we just need to
> move
> > >> forward towards the new approach and leave the old behind...
> > >>
> > >> Jeremy
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Jun 14, 2018 at 11:39 PM, Nir Sopher <n...@qwilt.com> wrote:
> > >>
> > >> > Hi,
> > >> > I'm with Jeremy on that.
> > >> > The "use_tenancy" flag came to allow simple transition to the
> tenanted
> > >> > world:
> > >> > On the transition, the TC owner should adjust all tenancies, most
> > >> > importantly create a "root tenant" admin, and only then put the
> > >> use_tenancy
> > >> > flag on.
> > >> >
> > >> > For 3.0 I believe that tenancy should become mandatory - transition
> > >> period
> > >> > done.
> > >> > A TC that does not need tenants, should just put all elements under
> > the
> > >> > root tenant. No need to maintain two pathes in the code....
> > >> >
> > >> > We can do the same for "role/capability" - adding a global knob just
> > for
> > >> > the transition.
> > >> >
> > >> > Nir
> > >> >
> > >> > On Thu, Jun 14, 2018 at 9:38 PM, Robert Butts <r...@apache.org>
> wrote:
> > >> >
> > >> > > >will the self-service stuff rob butts is working on be affected
> in
> > any
> > >> > > way? Will self-service truly be turned off via a parameter?
> > >> > >
> > >> > > What I'm working on, change integrity, shouldn't be affected by
> > turning
> > >> > off
> > >> > > tenancy/roles/capabilities.
> > >> > >
> > >> > > And we shouldn't turn off the API-visible parts of what I'll be
> > doing:
> > >> DS
> > >> > > snapshots, server snapshots, etc.
> > >> > >
> > >> > > We should be able to turn off the complex permissions system for
> > >> > > self-service, while still retaining safe change integrity via the
> > >> > timestamp
> > >> > > system.
> > >> > >
> > >> > > >it would be nice if TC 3.0 made tenancy / roles & capabilities a
> > >> > > requirement
> > >> > >
> > >> > > Requiring tenancy/roles/capabilities would certainly make the code
> > >> nicer,
> > >> > > but I'm afraid it'll make the software much more difficult to use,
> > for
> > >> > > users who want an internal CDN, and have no need for a complex
> > >> > permissions
> > >> > > framework.
> > >> > >
> > >> > > @mitchell852 Is it possible to add GUI shims in Traffic Portal,
> > and/or
> > >> > API
> > >> > > helpers, to make the interface pretend like
> > tenancy/roles/capabilities
> > >> > > don't exist? E.g. to grant all permissions and the root tenant to
> > all
> > >> > users
> > >> > > on user-creation, if the "use_self_service" config flag is set? So
> > all
> > >> > the
> > >> > > code can keep working the same way, but people who don't need
> > >> > > tenancy/roles/capabilities can still have the existing simpler
> > >> interface?
> > >> > > How difficult would that be?
> > >> > >
> > >> > >
> > >> > > On Thu, Jun 14, 2018 at 12:18 PM, Jeremy Mitchell <
> > >> mitchell...@gmail.com
> > >> > >
> > >> > > wrote:
> > >> > >
> > >> > > > I like the idea but what will it really mean to turn off
> > >> > > use_self_service.
> > >> > > > I know it will mean tenancy will be disabled and API permissions
> > >> won't
> > >> > be
> > >> > > > checked against a user's capabilities, but will the self-service
> > >> stuff
> > >> > > rob
> > >> > > > butts is working on be affected in any way? Will self-service
> > truly
> > >> be
> > >> > > > turned off via a parameter?
> > >> > > >
> > >> > > > IMO it would be nice if TC 3.0 made tenancy / roles &
> > capabilities a
> > >> > > > requirement. No more turning it on and off. The scope of what
> you
> > see
> > >> > is
> > >> > > > dictated by your tenancy and the api's that you have access to
> are
> > >> > > dictated
> > >> > > > by your capabilities.
> > >> > > >
> > >> > > > Jeremy
> > >> > > >
> > >> > > > On Thu, Jun 14, 2018 at 11:49 AM, Volz, Dylan <
> > >> dylan_v...@comcast.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi Traffic Controllers,
> > >> > > > >
> > >> > > > > I am working on enforcing the roles->capabilities system as a
> > >> > > replacement
> > >> > > > > for the soon-to-be legacy priv level system. Like tenancy this
> > is a
> > >> > > > feature
> > >> > > > > moving us towards self-service; so to minimize our
> code/behavior
> > >> > paths
> > >> > > > > I would like to propose renaming the use_tenancy parameter to
> > >> > > > > use_self_service, so that if it is turned on both tenancy and
> > >> > > > capabilities
> > >> > > > > are applied. This prevents some hairy cases arising when
> > >> capabilities
> > >> > > are
> > >> > > > > on and tenancy is off or vice versa. Let me know if you have
> any
> > >> > > > questions,
> > >> > > > > concerns, or suggestions.
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > Dylan
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
