ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Garus <garus....@gmail.com>
Subject Re: Model of permissions for Ignite 3
Date Thu, 08 Apr 2021 14:52:23 GMT
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.

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