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