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.
