[
https://issues.apache.org/jira/browse/RANGER-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313281#comment-16313281
]
Nigel Jones commented on RANGER-1850:
-------------------------------------
I have an example flow on the 'proxy auth' tab (along bottom) of a few diagrams
on draw.io -
https://www.draw.io/#Hplanetf1%2Fgaiandb-policy-ranger%2Fmaster%2Fdoc%2FGaian%20Data%20Access%20Diagrams
To answer
* userid Ernie is coming in from the JDBC application into gaiandb. As part of
that jdbc connect proxy-uid=gaiandb, proxy-pass=passw0rd is also sent
* gaiandb/passw0rd is used by the proxy auth module to authenticate with the
base gaiandb/derby authentication module
* Once connected the application does indeed have access to all the gaiandb
virtual tables in that there is no control over returned metadata (std jdbc
metadata) as gaiandb doesn't support policy management there (I think it should
in future). At a derby level gaiandb does have access to everything
* If the ranger plugin is installed, then access requests to individual
schemas, tables & columns will be controlled at that point (using user Ernie)
* This difference between derby's base auth model using grants etc & what
ranger does is not ideal... but requires significant work to better integrate
gaiandb & it's policy model into the derby security manager
* The userids configured to connect to the underlaying data sources that
gaiandb is virtualizing are defined in the gaiandb configuration files (on the
gaiandb code co-located with that data source typically). Whilst the user Ernie
can access these data sources, he does not have direct access to the
authentication details as such, or at least doesn't use them, that's the point
of using gaiandb as the virtualization layer
* A individual data source will have one set of credentials defined in the
gaiandb configuration ,so regardless of which user connects the same
credentials are used, so by definition they are NPAs
One point that does surface from this is that access to the gaiandb stored
procedures/derby tables that contain auth info for the underlying sources
should be restricted. I am not sure if this is possible but will look into it.
> 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)
