ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kseniya Romanova <romanova.ks....@gmail.com>
Subject Re: Model of permissions for Ignite 3
Date Mon, 12 Apr 2021 08:58:07 GMT
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.scherbakoff@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.d.g@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.goncharuk@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 <stkuzma@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.d.g@gmail.com>:
> > > >
> > > > > Sorry, I forgot to point the link
> > > > >
> > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > >
> > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <garus.d.g@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message