Hello, Igniters!
I want to propose to improve the way which we use
to present permissions in Ignite 3.
The model of permission in Ignite has a set of drawbacks.
The main drawback, IMHO: if you need to add a new permission,
you should change the core module by extended the 'SecurityPermission'
enum.
An approach like this becomes more challenged if new permission is created
for an extension.
The existing permission model is overcomplicated.
The SecurityPermission enum is divided into four groups,
and to determine whether a security subject has been given permission,
a plugin developer has to know what the permission group is.
But 'CACHE_CREATE' and 'CACHE_DESTROY' are included in two groups (system
operations and cache operations).
When 'CACHE_CREATE' ('CACHE_DESTROY') is treated as system permission,
it applies to all caches. In other cases, when 'CACHE_CREATE'
('CACHE_DESTROY') is treated as cache permission,
permission checking is executed with the account of the cache name.
IMHO, this logic is hard to understand.
There is no ability to represent compound operation as single permission
and so on.
So I would like to suggest using a permission model that is based on
'java.security.Permission'.
I prepared the concept [1] of how this model could look in Ignite.
Classes 'CachePermission', 'ComputePermission', and 'ServicePermission'
represent cache, compute,
and service permissions accordingly, allow wildcards, for example,
"org.apache.ignite.internal.*".
Class 'IgniteClusterPermission' represents permission without actions.
Interface 'GridSecurityProcessor' has a default implementation of the
'authorize' method.
'SecurityTestSuite' is green.
This representation of permission, IMHO, has the following advantages:
- A developer can easily add new permission without needing to touch the
core module.
- There is no need to implement complicated logic to authorize an operation
inside a security plugin.
But a developer has the opportunity to add custom logic.
- Wildcards for permission's name from a box, for example, 'new
CachePermission("x.y.z.*", "get,put")'.
- There is no need to implement 'SecurityPermissionSet' and a set of
methods from 'SecurityContex' ('xxxAllowed(String, SecurityPermission))'.
- We can define a security policy in a file as java does. It could simplify
work for administrators.
WDYT?
