> that ship has sailed when the roles/capabilities model was agreed upon
I don't agree. We could configure PostgreSQL Roles and Row Security Policies with the same capabilities, and the same UI. Users would click the "create role" or "assign capability" button, and the UI would issue an API call which issues a SQL command to create or assign the appropriate PostgreSQL Roles and Policies. Same model, different backend. On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <[email protected]> wrote: > > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_ > PostgreSQL users. There wouldn't be a single "trafficops" Postgres user, > every TO user would have their own user in Postgres itself. > > ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that ship > has sailed when the roles/capabilities model was agreed upon and is > currently in the works... > > Just to clarify for others, currently, when you login via LDAP and no user > is found in the tm_user table with the same username, we assign the > "read-only" role to the "current user". Rob doesn't think (and he's > probably right) that the "read-only" role is restrictive enough for these > LDAP only users. There are lots of GET routes that "read-only" users can > access that contain "sensitive" info... (depending on your definition of > sensitive) > > Anyhow, with this PR - > https://github.com/apache/incubator-trafficcontrol/pull/544 - the concept > of "capabilities" was introduced....roles can now have capabilities....so > in theory we could create a role called "Graph Viewer" or something which > maps to the cdn-graph-read capability that maps to certain api > endpoints...and then the "Graph Viewer" role would be automatically > assigned to LDAP only users..just an example. > > ^^ however the role/capabilities thing only applies to the API (not the > current TO UI) and was to be enforced by the API gateway > > In my opinion, trying to do what's best for the TO UI and the TO API at the > same time is very difficult, thus, my push to deprecate the TO UI and the > entire UI namespace of endpoints, in favor of the TO API and the API > namespace... TO API + API Gateway + Roles/Capabilities gives us more > granularity > > Jeremy > > > > > > On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo <[email protected]> wrote: > > > We use LDAP all the time. It's optional of course, but in our > > deployment nobody should be using local accounts unless they're not in > > LDAP for some reason (external users, portal users, etc). > > Application/API accounts could go either way, but users of the TO UI > > should use LDAP whenever possible to avoid having to manage multiple > > accounts/passwords. > > > > Basic enterprise operations best practices dictate centralized user > > management, and most enterprises do so using some sort of LDAP based > > directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on moving > > away from this model. If anything we need to make our LDAP > > implementation more flexible. > > -- > > Thanks, > > Jeff > > > > > > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <[email protected]> > > wrote: > > > I have a question in a similar vein, how often do we really use LDAP? > My > > > understanding is we created LDAP access to allow external users in to > see > > > our TO Graphs. Now that graphs are in Graphana is the need for LDAP > > still > > > needed? If we require anyone using TO or the TO API to be in the > > database > > > it would alleviate this LDAP security issue entirely. > > > > > > I also wonder if we shouldn't try to leverage transitioning our user > > > management to Postgres. Postgres has many options for authentication > > (as I > > > mentioned at the Summit), which would allow for more flexibility at TO > > > installations. > > > > > > -Dewayne > > > > > > On Wed, May 31, 2017 at 9:24 AM, Robert Butts < > [email protected]> > > > wrote: > > > > > >> We have a PR https://github.com/apache/incubator-trafficcontrol/pull/ > > 627 > > >> to > > >> change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops > > >> database to view non-sensitive information, like graphs and total CDN > > >> bandwidth. > > >> > > >> To be clear, users will still be able to authenticate with LDAP, as > > long as > > >> their user name is in the database. This only prevents access for LDAP > > >> users whose name is not in the database. > > >> > > >> If you have LDAP-only users who need access, you can simply add their > > user > > >> name to the Traffic Ops database to allow continued access. They don't > > even > > >> need a password, simply inserting the username is sufficient. > > >> > > >> LDAP is a security risk, especially for large organizations. Allowing > > all > > >> non-CDN personnel in the organization full information access, even > > >> read-only, means an attacker has only to compromise a single account > in > > the > > >> organization, and they can see the full list of CDN server IPs and > > FDQNs, > > >> as well as the specific ATS and CentOS versions, in order to take > > advantage > > >> of known exploits against those versions. > > >> > > >> Does anyone have any issues with that? Is anyone using LDAP without > > >> usernames in the database, who needs continued access? We just want to > > make > > >> sure we're not breaking anyone before we merge this, and figure out a > > >> solution if we are. Thanks, > > >> > > >
