incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew <andrew...@gmail.com>
Subject Re: Blur Console User Management
Date Wed, 25 Jun 2014 03:14:08 GMT
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)
Therefore we should not use a security provider to setup the user's
security attributes.

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.

Developers need the ability to search the data using different user
scenarios in order to mimic the usage of the customers. Multiple users
defined in the JSON file would be a good solution to this as it would allow
the admins to setup multiple user scenarios that the developers could then
use.
  A more complicated solution would be to allow the user's security
attributes to be custom defined through the UI. I don't think this would
add much value, and it would make the interface much more confusing.

More Thoughts?

Andrew



On Tue, Jun 24, 2014 at 10:13 PM, Chris Rohr <rohr.chris@gmail.com> wrote:

> In conversations I've had on my projects there have been questions of how
> things are secured through the console.  There are a couple of things that
> exist today and then there are some ideas that I would like to get feedback
> on.
>
> What is there today?
>
> 1. If your Blur cluster is setup to use security on the data through the
> UserContext paradigm, then in blur-site.config you can setup a config value
> that points to a JSON file with the properties needed for data to come
> back.  The draw back with this is that there is only one possible user and
> all "users" of the console are sharing that configured user.
>
> 2. Access to the console can be restricted as it is assumed that the
> console will run on a controller node and you could lock down access to the
> port running the console.
>
> Other ideas that have come up:
>
> 1. Changing the JSON file to allow the creation of multiple users and
> having the UI have the ability to switch users.  This gives the ability to
> see the data from different real life access control definitions, but all
> console users still have access to everything.
>
> 2. Setup some sort of user state (maybe through plugable providers) and
> then true logins can be created to the console with permissions defined by
> the provider implementation.
>
> Thoughts?
>
> Chris
>

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