incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <>
Subject Re: Blur Console User Management
Date Sat, 28 Jun 2014 12:43:18 GMT

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?


On Wed, Jun 25, 2014 at 8:34 AM, Tim Williams <> wrote:

> On Tue, Jun 24, 2014 at 11:14 PM, Andrew <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message