It appears there are 2 distinct questions here. 1. where is the mapping between ldapgroups and application roles defined?
One approach is taking shortname of ldapgroups as rolename and interpreting all the members of the group has the named application role. Other approach is to have a mapping file, file snippet or table. The exact location where it goes is open for discussion. 2. To what level do we want to support priveleges? a) service b) service + method c) service + resource path + method I think it would be better if Knox supports (c) service + resource path + method. Then all options a, b, c are available as deployment choices. There could be a customer with a Knox instance that is used primarily as secure HDFS gateway with fine access control. He could deny all access to job submission and grant fine grained access permissions to files. The doc should clearly call out having fine grained file access control and granting job submit permissions at the same time is erroneous configuration. We could also try to detect and warn on such a configuration. Thanks Dilli On Tue, Nov 19, 2013 at 1:29 PM, larry mccay <[email protected]> wrote: > That is an interesting point. > Read/Write permissions to an entire service is rather course but there may > be some value there. > > Not being able to do what your second example illustrates feels bad but > it's not like that isn't possible closer to the resource. > I say leave it out - I wouldn't want someone to confuse this level of > policy with protected all access to those resources - since this is only > the REST channel to it. > > The question remaining is whether: > > super-data-admin= > WEBHDFS:GET,PUT,POST,DELETE > > data-admin= > WEBHDFS:GET,PUT,POST > > this level of policy adds value over a service level toggle yes/no. > > I think that it probably does. > > We could lock the REST channel down to GETs across all of the services if > we wanted to. > > > > On Tue, Nov 19, 2013 at 3:53 PM, Kevin Minder > <[email protected]>wrote: > > > We do need to clarify whether or not "being in the VERB business" implies > > being in the multiple URL business. > > Specifically I would prefer policy be written at the service level not > the > > resource level. > > > > data-admin= > > WEBHDFS:GET,PUT,POST,DELETE > > > > not > > > > data-scientist= > > /webhdfs/v1/{user}/**:GET,PUT,POST,DELETE > > /webhdfs/v1/**:GET > > > > but I'd like to hear discussion. > > > > > > On 11/19/13 3:46 PM, larry mccay wrote: > > > >> Yes, I have gone back and forth on that a number of times. > >> I'm not so sure that optional would end up meaning rarely used. > >> We either want to be in that business or not. > >> > >> What is interesting is that we as the REST API Gateway maybe should be > >> interested in the verb based protection. > >> > >> I'm not sure that I can make myself feel strongly about one way over the > >> other. I may lean slightly toward staying out of that business but other > >> related efforts may actually want to specify read vs write control. > >> > >> I just want it know that if we do support verb based policy semantics > then > >> we cannot allow folks to hurt themselves with it. > >> JEE made a mistake here long ago and it provides an opportunity for verb > >> tampering in order to bypass policy. > >> > >> Any indication of verb specific policy requires any request for the > >> non-specified verbs to be denied. It is not likely that we would mess > this > >> up but I just want to make sure. > >> > >> > >> > >> > >> On Tue, Nov 19, 2013 at 3:29 PM, Kevin Minder > >> <[email protected]>wrote: > >> > >> Hi Everyone, > >>> I wanted to get some of by RBAC enhancement thoughts down on paper. > >>> > >>> The key concept is really the notions of a Knox roles and privileges. > A > >>> role is typically (partially) defined as a collection of privileges so > >>> lets > >>> start there. For this discussion I will define a privilege as the > >>> combination of a "service role" (e.g. WEBHDFS) and HTTP verbs (e.g. > GET, > >>> PUT, POST, DELETE, etc.). So example privileges might be: > >>> > >>> WEBHDFS: GET > >>> OOZIE: GET,POST > >>> HIVE: GET > >>> > >>> Roles then are a named combination of privileges. Some examples: > >>> > >>> data-admin > >>> WEBHDFS:GET,PUT,POST,DELETE > >>> data-scientist > >>> WEBHDFS:GET > >>> OOZIE: GET,POST > >>> HIVE: GET > >>> > >>> Then Knox should be able to map groups obtained at authentication time > >>> (e.g. LDAP) to one or more of these roles. > >>> This does lead to the natural questions: > >>> 1) How is the group->role mapping managed? > >>> 2) There needs to be a simple way to have the have the roles come > >>> directly > >>> from LDAP such that mapping at the Knox level isn't required > >>> > >>> Seeing this on paper does raise in issue for me that might make the > HTTP > >>> verb part a problem. > >>> A "data-scientist" should probably always have HDFS GET,PUT,POST,DELETE > >>> for /user/{uid} directory but the point of the role may be to prevent > >>> file > >>> deletion. > >>> But I don't think Knox should be in the resource authorization > business. > >>> So perhaps a role is just a collection of services (i.e. without verb > >>> control) or would that just be optional and rarely used? > >>> > >>> Kevin. > >>> > >>> -- > >>> CONFIDENTIALITY NOTICE > >>> NOTICE: This message is intended for the use of the individual or > entity > >>> to which it is addressed and may contain information that is > >>> confidential, > >>> privileged and exempt from disclosure under applicable law. If the > reader > >>> of this message is not the intended recipient, you are hereby notified > >>> that > >>> any printing, copying, dissemination, distribution, disclosure or > >>> forwarding of this communication is strictly prohibited. If you have > >>> received this communication in error, please contact the sender > >>> immediately > >>> and delete it from your system. Thank You. > >>> > >>> > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > > to which it is addressed and may contain information that is > confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
