incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Blur Console User Management
Date Wed, 25 Jun 2014 12:34:58 GMT
On Tue, Jun 24, 2014 at 11:14 PM, Andrew <andrew.va@gmail.com> 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

Mime
View raw message