Hi,

We're getting close to merging in the Integrated Security code under
GEODE-17. This work closely matches the spec detailed here [1], but also
has some differences:

This code will not support security for the developer REST API, only for
the admin API as used by gfsh over HTTP.

APIs (methods) will be protected using a *ResourceOperation* annotation.
These annotations consist of a *Resource* (noun) and *OperationCode* (verb)
tuple. The original spec had defined a hierarchy of operation codes with
the lowest level detailing over 50 operation codes (and didn't use the
notion of a Resource). Because many of the operations fall into clear
categories we've decided to simplify definitions considerably and will be
defining the following Resources and OperationCodes:

*Resources*

   - Data
   - Cluster

*OperationCodes*

   - Manage
   - Read
   - Write

Bear in mind that these ResourceOperations will only be applied to the new
security coverage we're working on, namely JMX, gfsh and Admin REST.

With that in mind, I'm referencing a spreadsheet [2] which details every
gfsh and JMX operation with the Resource and OperationCode applied to them.
The columns to focus on are 'NewResource' and 'NewOperation'. The
'Resource' and 'Operation' columns are what we had originally started with.
With fewer options and permutations it will be much easier for someone
building a security implementation or configuring an implementation, to
understand the scope of permissions which can be applied to any given user.

If you have some time please take a look at the spreadsheet and provide any
feedback especially regarding the granularity of permissions we're wanting
to apply.

Thanks
--Jens


[1] https://cwiki.apache.org/confluence/display/GEODE/Integrated+Security
[2]
https://drive.google.com/file/d/0B90JiJqPpx8TR1dFWHRFYWV0bjdBeXR3aHVLTUs0X2l0YmFv/view?usp=sharing

Reply via email to