Sorry, I forgot to point the link 1. https://github.com/apache/ignite/pull/8989
чт, 8 апр. 2021 г. в 17:50, Denis Garus <garus....@gmail.com>: > 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? >