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 >> > > > > >> > > > >> > > >> > >>
