I'm fine merging Rob's PR - https://github.com/apache/incubator-trafficcontrol/pull/627
as long as it's understood that pure LDAP users (users with no user in the tm_user table) will not work for 99% of the UI or the API. If they want to get back that 99%, they need to have a user created for them in the tm_user table where username=their ldap username... jeremy On Thu, Jun 1, 2017 at 12:20 PM, Dave Neuman <[email protected]> wrote: > 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, > > > > >> > > > > > > > > > >
