[
https://issues.apache.org/jira/browse/RANGER-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312899#comment-16312899
]
Nigel Jones edited comment on RANGER-1850 at 1/5/18 10:36 AM:
--------------------------------------------------------------
Thanks for the feedback
a) proxy auth fail -- I think both approaches make some sense. I'll think about
which makes best sense for now, and plan to discuss it in some face to face
meetings next week. Note that to some extent this is a shorter term fix since
there's a lot more to do (IMO) for a full proxy support. for example I'd like
to be able to grant specific permissions to the service account to permit it
the proxy capability, and potentially vice versa to allow a user to be
impersonated. This starts getting into the derby security manager in more
detail, so should be based on using more up to date derby code (current) and
working with the derby community. There's also here a tension between the
implementation of the policy plugin and the security manager. We can't do that
just yet so a 'sufficient' solution is all I'm going for at this point.
b) create-schema well.. creates a schema for the user. I wouldn't have expected
it to be needed either - since my queries are against fully qualified views
like gaiandb.vcustomer -- but this fails with the older derby code gaiandb is
using. From the mailing list (derby) it appears this is a bug as it only
affects views and not tables.. but I can't move to current derby code without
gaiandb rejigging. We've already started work to rebuild gaiandb and start
updating libraries, but that is a longer term effort. So for now the pragmatic
workaround is to add this flag. I did this in the plugin to reduce
impact/complexity/odd errors from users of the code. Similar to a) it's a
reflection of a minimal solution pending a much bigger change to bring gaiandb
up to current code levels
c) Which docs are you referring to? If gaiandb - correct. this is an additional
plugin to be applied on top. In the future I hope we can make this a core
capability, but this is a pragmatic approach on existing levels. If the docs
for this plugin, agree that work isn't complete yet. Feel free to clarify what
info you'll need and I'll add it in the README.md once the code moves into the
ranger repo
d) For the use case I'm addressing, auth against oracle is via the NPA defined
for oracle (different to the gaiandb NPA), and those credentials are managed
via the gaiandb configuration as is the case today. As far as gaiandb/derby is
concerned the 'user' is the proxied user ie nigel, david etc as that is what
the 'User' parm on connection is set to (one reason I used it with additional
proxy-uid, proxy-password for the uid/password I wanted to use for the
authentication check). So once the query leaves derby we are purely using the
oracle NPA, and no attempt is made to 'pass down' the actual end user to the
db. This would be very useful for audit, but the method to do this will vary by
each db/source gaiandb supports. It would need more support in gaiandb itself
for a framework, and then specifics for each supported db. Again we're up
against the fact changes need to be made in this area in any case, so it didn't
seem prudent to go down this route at this point.
was (Author: jonesn):
Thanks for the feedback
a) proxy auth fail -- I think both approaches make some sense. I'll think about
which makes sense. Note that to some extent this is a shorter term fix since
there's a lot more to do (IMO) for a full proxy support. for example I'd like
to be able to grant specific permissions to the service account to permit it
the proxy capability, and potentially vice versa to allow a user to be
impersonated. This starts getting into the derby security manager in more
detail, so should be based on using more up to date derby code (current) and
working with the derby community. There's also here a tension between the
implementation of the policy plugin and the security manager. We can't do that
just yet so a 'sufficient' solution is all I'm going for at this point.
b) create-schema well.. creates a schema for the user. I wouldn't have expected
it to be needed either - since my queries are against fully qualified views
like gaiandb.vcustomer -- but this fails with the older derby code gaiandb is
using. From the mailing list (derby) it appears this is a bug as it only
affects views and not tables.. but I can't move to current derby code without
gaiandb rejigging. We've already started work to rebuild gaiandb and start
updating libraries, but that is a longer term effort. So for now the pragmatic
workaround is to add this flag. I did this in the plugin to reduce
impact/complexity/odd errors from users of the code. Similar to a) it's a
reflection of a minimal solution pending a much bigger change to bring gaiandb
up to current code levels
c) Which docs are you referring to? If gaiandb - correct. this is an additional
plugin to be applied on top. In the future I hope we can make this a core
capability, but this is a pragmatic approach on existing levels. If the docs
for this plugin, agree that work isn't complete yet. Feel free to clarify what
info you'll need and I'll add it in the README.md once the code moves into the
ranger repo
d) For the use case I'm addressing, auth against oracle is via the NPA defined
for oracle (different to the gaiandb NPA), and those credentials are managed
via the gaiandb configuration as is the case today. As far as gaiandb/derby is
concerned the 'user' is the proxied user ie nigel, david etc as that is what
the 'User' parm on connection is set to (one reason I used it with additional
proxy-uid, proxy-password for the uid/password I wanted to use for the
authentication check). So once the query leaves derby we are purely using the
oracle NPA, and no attempt is made to 'pass down' the actual end user to the
db. This would be very useful for audit, but the method to do this will vary by
each db/source gaiandb supports. It would need more support in gaiandb itself
for a framework, and then specifics for each supported db. Again we're up
against the fact changes need to be made in this area in any case, so it didn't
seem prudent to go down this route at this point.
> 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)
