On Fri, Jun 9, 2017 at 5:38 PM, Bruno Wolff III <br...@wolff.to> wrote:
> On Thu, Jun 08, 2017 at 22:37:34 -0700, > Ken Tanzer <ken.tan...@gmail.com> wrote: > >> >> My approach was to have the initial connection made by the owner, and then >> after successfully authenticating the user, to switch to the role of the >> site they belong to. After investigation, this still seems feasible but >> imperfect. Specifically, I thought it would be possible to configure such >> that after changing to a more restricted role, it would not be possible to >> change back. But after seeing this thread ( >> > > How are you keeping the credentials of the owner from being compromised? > It seems if you are worried about role changing, adversaries will likely > also be in a position to steal the owner's credentials or hijack the > connection before privileges are dropped. > Seems to me they are separate issues. App currently has access to the password for accessing the DB. (Though I could change that to ident access and skip the password.) App 1) connects to the DB, 2) authenticates the user (within the app), then 3) proceeds to process input, query the DB, produce output. If step 2A becomes irrevocably changing to a site-specific role, then at least I know that everything that happens within 3 can't cross the limitations of per-site access. If someone can steal my password or break into my backend, that's a whole separate problem that already exists both now and in this new scenario. Cheers, Ken -- AGENCY Software A Free Software data system By and for non-profits *http://agency-software.org/ <http://agency-software.org/>* *https://agency-software.org/demo/client <https://agency-software.org/demo/client>* ken.tan...@agency-software.org (253) 245-3801 Subscribe to the mailing list <agency-general-requ...@lists.sourceforge.net?body=subscribe> to learn more about AGENCY or follow the discussion.
