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. 2. Add a provider mechanism to add basic Role based access to features in the tool. 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 >
