Github user sourav-mazumder commented on the pull request:
https://github.com/apache/incubator-zeppelin/pull/681#issuecomment-180820970
Hi Prasad,
I also have similar opinion like Moon on the storing the permission.
However your design so far looks reasonably good though.
Here are my few comments/suggestions -
1. I do agree with you that Interpreter Authorization is complex. But the
examples you have provided, if I'm not missing anything, those are related to
Authentication of executing the target technology not related to the
interpreter itself. The authorization considerations for Interpreters should be
who can change an interpreter setting, who can execute an interpreter, who can
create a new interpreter from the existing interpreter set. So essentially you
need to plugin here the Role of a user which you'll get from enterprise
authentication/authorization system like LDAP. So as an example at the
enterprise level someone will typically setup say 2 types roles for users using
Zeppelin. Role type 1, say Zeppelin Administrator. Administrator will have
access to the setting of access control for all interpreters, can control the
users who can schedule running of his/her notebook (though I may be a notebook
author I need not have the ability to schedule it to run it any time as I may be
hogging enterprise cluster resource and impact some other higher priority
job), who can import/export, etc. Then Role type 2, say Regular User. This
Regular User will create the notebook, change the permission settings to
his/her notebook. Based on this Role the user will even have access to access
control setup for interpreters, notebook, scheduler.
2. Coming to Moon's point where you are storing the access control
information for every notebook and interpreters is very important. In my
opinion it should not be in the Notebook itself as it is a plain text
information and can be seen/exported by anyone whoever has access to the
Notebook folder (or can export the same). There are typically three ways one
can handle this. Firstly, you can store it as a separate encrypted file in a
secured folder in the file system. Only the Zeppelin process ( essentially the
super user who started the Zeppelin server) has access to that folder and can
do any change. Secondly to a target database. Or Thirdly even in LDAP . The
configurations for option 2 and 3 can come from a configuration again stored in
an encrypted file in a folder which only the super user (who typically starts
the zeppelin process) can access. You may start with any one implementation but
having a generic interface/abstraction (so that later on other implementations
can be
plugged in) is recommended.
3. I see you have assumed that there would be a separate authentication
component. To model the same with something which will typically be used I may
suggest you to refer to design/interfaces of Apache Knox. People would be using
Zeppelin a lot in their Hadoop Cluster and there would be good chance that they
will use Knox (Knox comes in most of the hadoop distribution) as a gateway
(which will in turn authenticate the users with enterprise level LDAP) to
authenticate users accessing Zeppelin. Basically Knox will do the
authentication and will pass the necessary roles to your module and then your
model can use them to differentiate between who is Zeppelin Administrator and
who is Regular User.
Hope this helps.
Regards,
Sourav
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
