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
