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