incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: Blur Console User Management
Date Tue, 01 Jul 2014 01:15:34 GMT
On Sat, Jun 28, 2014 at 8:43 AM, Chris Rohr <rohr.chris@gmail.com> 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 <williamstw@gmail.com>
> wrote:
>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message