Hi Denis, Did you make any progress on this topic?
-Val On Wed, Apr 21, 2021 at 6:11 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Danis, > > Got it, thanks. Please provide the link to the IEP when you have one, I’d > be happy to review! > > -Val > > On Tue, Apr 20, 2021 at 12:21 AM Denis Garus <garus....@gmail.com> wrote: > >> Hello! >> >> We arranged that I prepare an IEP. >> If you have some ideas about what should be reflected in this IEP, do not >> hesitate to let me know. >> >> вт, 20 апр. 2021 г. в 02:06, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >> >> > Hi folks, >> > >> > Did you have a discussion? How did it go? Can someone summarize the >> > results? >> > >> > -Val >> > >> > On Mon, Apr 12, 2021 at 2:00 AM Kseniya Romanova < >> > romanova.ks....@gmail.com> >> > wrote: >> > >> > > Hi! Scheduled open call for Friday >> > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/277518672/ >> > > Please join to see the zoom link. Consulted with Denis Garus and put >> the >> > > topic as "Security", cause it's definitely wider than just >> permissions. >> > > >> > > Cheers! >> > > >> > > пн, 12 апр. 2021 г. в 09:25, Alexei Scherbakov < >> > > alexey.scherbak...@gmail.com >> > > >: >> > > >> > > > +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 >> > > > >> > > >> > >> >
