I do not support the position of what appears to be dramatically changing access without a tangible migration plan -- I feel like we should comply with the "principle of least surprise" in this case.
On Fri, Jun 2, 2017 at 8:28 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > 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 <neu...@apache.org> 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 <robert.o.bu...@gmail.com> > > 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 < > mitchell...@gmail.com> > > > 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 <els...@apache.org> > 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 < > > dewr...@gmail.com> > > > > > 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 < > > > > robert.o.bu...@gmail.com> > > > > > > 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, > > > > > >> > > > > > > > > > > > > > > >
