[
https://issues.apache.org/jira/browse/DRILL-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780584#comment-15780584
]
Nagarajan Chinnasamy edited comment on DRILL-5132 at 12/27/16 3:17 PM:
-----------------------------------------------------------------------
I guess these (external)session options are better maintained externally.
Hence, I am thinking of introdcuing a UserContextHandler that will be
instantiated by UserServer just after the authentication. Whatever
authenticator returns will be routed to UserContextHandler for further storage
for use by UDFs.
Flow would be:
1. UserServer authenticates using UserAuthenticator
2. UserAuthenticator returns (external)session Options (authToken plus anything
else) obtained from external system
3. UserServer completes building UserSession
4. UserServer passes (external)session Options and UserSession.getSessionId to
UserContextHandler
5. UserContextHandler is free to store the options in its own way and expose
them through UDFs
6. When UserServer is closed, UserContextHandler is closed (so that it can
clear the options from its own storage)
Above flow minimizes changes to Drill and management of external session
options also gets externalized.
was (Author: nagarajanchinnasamy):
I guess these (external)session options are better maintained externally.
Hence, I am thinking of introdcuing a UserContextHandler that will be
instantiated by UserServer just after the authentication. Whatever
authenticator returns will be routed to UserContextHandler for further storage
for use by UDFs.
Flow would be:
1. UserServer authenticates using UserAuthenticator
2. UserAuthenticator returns (external)session Options (authToken plus anything
else) obtained from external system
3. UserServer completes building UserSession
4. UserServer passes (external)session Options and UserSession.getSessionId to
UserContextHandler
5. UserContextHandler is free store the options in its own way and expose them
through UDFs
6. When UserServer is closed, UserContextHandler is closed (so that it clear
the options from its own storage)
Above flow minimizes changes to Drill and management of external session
options also gets externalized.
> 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)
