[
https://issues.apache.org/jira/browse/DRILL-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798455#comment-15798455
]
Veera Naranammalpuram commented on DRILL-5132:
----------------------------------------------
This is a great idea. I know at least one customer that plans to use something
like this. Are we adding this new concept of "tenantId" to the roles/groups
hierarchy? In a typical multi tenant environment, there are multiple tenants
that have multiple group roles that have multiple users. The most granular is
user the session is logged in as, which is part of one or more group roles
which is part of a larger tenant. Is the assumption correct? Any approach
should incorporate security throughout the hierarchy. Ex: the following
functions should be supported as well -
session_parameter(get_group(session_user())),
session_parameter(session_user())).
The UDF approach sounds good as well - but what will it call to retrieve to
what tenant a user belongs to? The concept of tenantId is great but it
introduces a new level of granularity fo the basic security model of Linux -
users are part of one or more groups. There could be ways you could talk to
LDAP, Kerberos servers to retrieve all attributes of a user but that's making
it too complicated.
> 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 Column
> * *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 parameter
> 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 'tenantId'.
> 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
(v6.3.4#6332)
