+1 We should rethink the security model in Ignite 3 and have a default RBAC based implementation, from my point of view. By default, no code should be written to enable and use it.
Let's schedule a meeting and discuss the details. вс, 11 апр. 2021 г. в 19:43, Denis Garus <garus....@gmail.com>: > Andrey, Alexey thank you for the feedback! > > > I suggest decoupling authentication from authorization > > Yes, it would be useful. Existing SecuritySubject and SecurityContext > require reworking. > > > I think it would be great to have a default implementation of > user-role-permission model > > Completely agree it is a cool idea. Ignite should have more default > implementation referred to security. > > > Should we have a community meeting to discuss this? > > Yes, it would be great. > The wish list for Ignite 3 does not contain security improvement that, > IMHO, is wrong. > We should fix that oversight on early-stage Ignite 3 development. > > пт, 9 апр. 2021 г. в 18:47, Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > Hello Denis, Andrey, Igniters, > > > > Why don't we take a step further in improving the security model in > Ignite > > 3? I think it would be great to have a default implementation of > > user-role-permission model in Ignite to be on par with security models of > > widely-used databases. This will complement community efforts in making > > most of the Ignite 3 behavior to be changeable in runtime. > > > > WDYT? Should we have a community meeting to discuss this? > > > > > > чт, 8 апр. 2021 г. в 23:54, Andrey Kuznetsov <stku...@gmail.com>: > > > > > 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. > > > > > > -- Best regards, Alexei Scherbakov
