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 On Fri, Feb 5, 2016 at 11:11 PM, Leemoonsoo <g...@git.apache.org> wrote: > Github user Leemoonsoo commented on the pull request: > > > https://github.com/apache/incubator-zeppelin/pull/681#issuecomment-180711174 > > Thanks for great contribution. Tested working nicely. > > Can 'Note Permissions' have white background? like 'interpreter > binding' ? If you need help, me or maybe Damien can help on styling. > > Another one is - actually i should ask earlier - recently there were > [discussion]( > http://apache-zeppelin-users-incubating-mailing-list.75479.x6.nabble.com/Multiple-spark-interpreters-in-the-same-Zeppelin-instance-td2171.html) > about notebook file portability regarding interpreter selection. > > Current design save permission information into notebook file. But > notebook can be exported and imported into the Zeppelin instance that has > different set of user/group exists. (either using import/export feature or > copying notebook file into file system) > > So, do you have good idea to make note permission feature gracefully > aware notebook portability? > > > > --- > 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. > --- >
