Just because we *can* do something doesn't mean we *should* do something. I don't think we should try to over engineer this part of the system and make it any more complicated than it needs to be. I think Rob's PR should be merged so that LDAP users, by default, have very limited capabilities.
On Thu, Jun 1, 2017 at 10:16 AM, Robert Butts <[email protected]> wrote: > > 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, > > > >> > > > > > >
