On Sat, Jun 28, 2014 at 8:43 AM, Chris Rohr <[email protected]> wrote:
> Tim, > > While we may need to get to the point where this can run in a container, > Andrew made a good point that this tool is supposed to be for developers > and maintainers of Blur itself. I think the primary need behind my > question was that I have users that I want to have read/search access but > not update access to the tool itself. The other need is the ability to > verify Blur security by faking out various real user's accesses while > performing a search. > > So in the short term, I think we should do the following: > > 1. Update the current globalUserProperties setup in the console to allow > for a mapping of fake users to security properties and allow the UI to > switch between the fake users. > I think that it's fine for the current version but we should look at adding security to the entire Blur stack. > > 2. Add a provider mechanism to add basic Role based access to features in > the tool. > This sounds like a good idea. Aaron > > Thoughts on this? > > Chris > > > On Wed, Jun 25, 2014 at 8:34 AM, Tim Williams <[email protected]> > wrote: > > > On Tue, Jun 24, 2014 at 11:14 PM, Andrew <[email protected]> wrote: > > > Chris, > > > I think the security implementation really depends on who the users of > > the > > > blur console are. > > > I don't think we want the blur console to be used by customers and we > > > should focus on providing features to privileged users (developers) > > > > > > We definitely could use a pluggable security provider to secure access > to > > > the console though. This would allow the console to run without using a > > > firewall to protect it. LDAP groups/roles, JSON user file, and UNIX > > > users/groups would all be useful security providers. > > > > I wonder if it'd help to decompose "access" a bit? I think of three > > things: > > > > 1) Access to the console at all - if this is a concern, the console > > should be deployed in a proper container and let container security > > handle it. > > > > 2) Data access - it'd be helpful if the console accepted a security > > filter to be applied to queries I think. For example, I could put a > > servlet filter in front of the console and add an request attribute > > BLUR_AUTH_FILTER (or somesuch) and the console would include it as a > > filter. > > > > 3) Feature access - i can see where even amongst 'privileged' devs we > > might want to limit the features available. For example, maybe I want > > to limit the number of folks that can disable/remove tables to only a > > subset of folks - perhaps by just disabling the whole "Tables" > > tab/feature? It's hard to think of an elegant solution to this one... > > perhaps if the URLs were real vs. fragments, folks could just manage > > themselves with container security? this would also allow the console > > to be a generic front-end for power-users (e.g. by providing access > > only to the query feature/tab). > > > > I don't [yet] use blur's built-in user/security stuffs so I suppose > > I'm not really answering the question, just giving some broader > > thoughts on the subject:) > > > > Thanks, > > --tim > > >
