drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nagarajan Chinnasamy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5132) Context based dynamic parameterization of views
Date Wed, 04 Jan 2017 20:10:58 GMT

    [ https://issues.apache.org/jira/browse/DRILL-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799201#comment-15799201

Nagarajan Chinnasamy commented on DRILL-5132:

Yes. You are correct. TenantId is just one of the such variables used in the example above.

I am assuming there will be a REST-API hosted by the external system to serve such session
values. UDFs can invoke this REST-API. Interfacing with LDAP or any other such system can
be hidden behind this REST-API.

Its up-to you to write your own set of UDFs to interface with the REST-API.

We need to iron out what is the framework that Drill should have to support such UDFs.

> Context based dynamic parameterization of views
> -----------------------------------------------
>                 Key: DRILL-5132
>                 URL: https://issues.apache.org/jira/browse/DRILL-5132
>             Project: Apache Drill
>          Issue Type: Wish
>          Components:  Server
>            Reporter: Nagarajan Chinnasamy
>            Priority: Critical
>              Labels: authentication, context, isolation, jdbcstorage, multi-tenancy,
session-context, session-parameter
> *Requirement*
> Its known that Views in SQL cannot have custom dynamic parameters/variables.  Please
refer to [Justin Swanhart|http://stackoverflow.com/users/679236/justin-swanhart]'s response
to [this SO question|http://stackoverflow.com/questions/2281890/can-i-create-view-with-parameter-in-mysql]
in handling dynamic parameterization of views. 
> [The PR #685|https://github.com/apache/drill/pull/685] [DRILL-5043|https://issues.apache.org/jira/browse/DRILL-5043?filter=-2]
originated based on this requirement so that we could build views that can dynamically filter
records based on some dynamic values (like current tenant-id, user role etc.) 
> *Since Drill's basic unit is a View... having such built-in support can bring in dynamism
into the whole game.*
> This feature can be utilized for:
> * *Data Isolation in Shared Multi-Tenant environments* based on Custom Tenant Discriminator
> * *Data Protection in building Chained Views* with Custom Dynamic Filters
> To explain this further, If we assume that:
> # As and when the user connection is established, we populate session context with session
 parameters such as:
> #* Tenant ID of the currently logged in user
> #* Roles of the currently logged in user
> # We expose the session context information through context-based-functions such as:
> #* *session_id* -- that returns unique id of the session
> #* *session_parameter('<parameter-name>')* - that returns the value of the session
> then a view created with the following kind of query:
> {code}
> create or replace view dynamic_filter_view as select
>    a.field as a_field
>    b.field as b_field
> from
>    a_table as a
> left join
>    b_table as b
> on
>    a.bId = b.Id
> where
>    session_parameter('tenantId')=a.tenantId
> {code}
> becomes a query that has built-in support for dynamic parameterization that only returns
records of the tenant of the currently logged in user. This is a very useful feature in a
shared-multi-tenant environment where data is isolated using multi-tenant-descriminator column
> When building chained views this feature will be useful in filtering records based on
context based parameters.
> This feature will particularly be useful for data isolation / data protection with *jdbc
storage plugins* where drill-authenticated-credentials are not passed to jdbc connection authentication.
A jdbc storage  has hard-coded, shared credentials. Hence the the responsibility of data isolation
/ data protection lies with Views themselves. Hence, the need for built-in support of context
based dynamic parameters in Views.
> *Design/Implementation Considerations:*
> * Session parameters can be obtained through authenticators so that custom authenticators
can return a HashMap of parameters obtained from external systems.
> * Introduce SessionContext to hold sessionId and sessionParameters
> * Implement context based functions session_id and session_parameter()

This message was sent by Atlassian JIRA

View raw message