"Row" level access?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

"Row" level access?

jewzaam
Administrator
Also known as: how could we restrict users access to a subset of an entity's data?

For example, allow a user access to data for their region only.  Or allow partner / vendor access to only their data.

My thought on this is to add a way to define a query that gets added to any request for that principal.  Client requests X, the real query becomes $and { X, query-restriction }

Major hurdle with this will be managing it.  Where is it stored, who can update it, how is it maintained, etc.
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

dcrissman
Would the projection make more sense? We already filter responses based on roles. Maybe we have a RegionProjection?
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

bserdar
In reply to this post by jewzaam
This can probably be included in #125.

On Mon, Jan 19, 2015 at 2:07 PM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> Also known as: how could we restrict users access to a subset of an entity's
> data?
>
> For example, allow a user access to data for their region only.  Or allow
> partner / vendor access to only their data.
>
> My thought on this is to add a way to define a query that gets added to any
> request for that principal.  Client requests X, the real query becomes $and
> { X, query-restriction }
>
> Major hurdle with this will be managing it.  Where is it stored, who can
> update it, how is it maintained, etc.
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/Row-level-access-tp303.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

dcrissman
It seems to me that we might want to have a way define this more broadly than just on the entity level. What if the access block is inadvertently defined improperly on some random entity? This could have significant legal or contractual ramifications. I guess what I am asking is, from a SecEng perspective, would it be good to also have a way to lock down certain data points at a higher level in order to prevent accidents?
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

bserdar
That assumes a common denominator across multiple entities. Same thing
can be achieved by defining whetaver the constraint we use to limit a
certain role for a subset of the documents of an entity to other
entities.

On Mon, Jan 19, 2015 at 2:35 PM, dcrissman [via lightblue-dev]
<[hidden email]> wrote:

> It seems to me that we might want to have a way define this more broadly
> than just on the entity level. What if the access block is inadvertently
> defined improperly on some random entity? This could have significant legal
> or contractual ramifications. I guess what I am asking is, from a SecEng
> perspective, would it be good to also have a way to lock down certain data
> points at a higher level in order to prevent accidents?
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/Row-level-access-tp303p306.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

jewzaam
Administrator
In reply to this post by bserdar
To make it easier to find, looks like we have an issue around this already but without any discussion.

"Ability to restrict access based on document contents"
https://github.com/lightblue-platform/lightblue-core/issues/125
Reply | Threaded
Open this post in threaded view
|

Re: "Row" level access?

jewzaam
Administrator
In reply to this post by bserdar
If it's done at a higher level (proxy?) then it would require qurey rewriting.  Something has to know the constraints to apply to the request for the incoming roles.  If document level restrictions are acceptable then it makes sense to me to be a query associated with a role.  If additional restrictions are necessary, such as only returning a subset of array data within a document, then projections are necessary.

Another to consider is what if we have multiple roles for an operation with query/projection restrictions and a request comes from a client that is a member of two or more of such roles?  Is it an AND or an OR between those restrictions?  We'll have to be clear on that.