[
https://issues.apache.org/jira/browse/RANGER-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312967#comment-16312967
]
Nigel Jones edited comment on RANGER-1850 at 1/5/18 11:16 AM:
--------------------------------------------------------------
a) Point noted :-)
b) Yes that is correct (I was aware of it, I should add to the docs), it's a
current limitation caused by derby/us using backlevel.
e) Correct we are not using this approach as this requires changes to
applications and means derby sees one user (like 'gaiandb') whilst some the
ranger plugin operates on another. It also means only sql statement execution
uses this proxied user id, whilst jdbc metadata queries etc do not. Confusing
and more divergent from base derby security & the way the derby security
manager works. By using the proper derby plugin approach derby consistently
sees the same userid as gaian regardless of the API call. We are also closer
then to the intent of the derby community in terms of extension points, and can
build on that approach as we update gaiandb in future
f) The plugin is called when a connection is made from an application, via the
jdbc driver, into gaiandb. It's right at the top.. It is not called per data
source (that is something gaiandb manages using the auth details configured in
gaiandb_config.properties for each source)
was (Author: jonesn):
a) Point accepted :-)
> Impersonation/proxy user support for gaiandb ranger plugin
> ----------------------------------------------------------
>
> Key: RANGER-1850
> URL: https://issues.apache.org/jira/browse/RANGER-1850
> Project: Ranger
> Issue Type: Sub-task
> Components: plugins
> Reporter: Nigel Jones
> Attachments: GaianDBAuth.docx
>
>
> Applications/users could connect to gaianDB using their own authentication
> information - for example userid/password in the simple case. Here the ranger
> plugin will use that id for policy checks.
> However in a multi tiered architecture a service id (aka non personal
> account) may be used, and somehow the user to be impersonated is passed via
> an additional property. This has a number of implications to the system
> configuration, derby/gaiandb configuration & the plugin implementation.
> Opening this Jira as a placeholder and will add a document soon (++days) on
> the same to capture some of the discussion around this area in recent days.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
