[ 
https://issues.apache.org/jira/browse/RANGER-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312949#comment-16312949
 ] 

David Radley commented on RANGER-1850:
--------------------------------------

[~jonesn] thanks for the clarification - that makes sense. 
a) My thinking is that authentication strategies should always be on the 
cautious side unless there are best practices or precedence you have found to 
indicate otherwise.    
b) It sounds like we are creating a schema for the supplied userid. So we will 
proliferate schemas if there are a lot of users - one for every user.  

A couple more comments: 
e) From your docs, you mention:
SELECT * FROM LT -- GDB_CREDENTIALS
I assume we are not going to use this select form - as your plugin will 
effectively do this.
f) Can I confirm when your authentication plugin runs. Is it once for every 
data source that is referenced by a query or once for every connection that 
those data sources use?










> 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)

Reply via email to