Hi Denis! The idea and prototype look great.
I'd like to highlight one arguable point. Default authorization implementation still assumes there are permissions provided in SecuritySubject. In turn, authentication is still responsible for filling these permissions. I suggest decoupling authentication from authorization, so that GridSecurityProcessor implementation is fully responsible for obtaining permissions for SecuritySubject given on authorization. In particular, implementation can choose an existing behavior of bundling permissions with SecuritySubject. Makes sense? чт, 8 апр. 2021 г. в 17:52, Denis Garus <garus....@gmail.com>: > 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? > > > -- Best regards, Andrey Kuznetsov.
