Model of permissions for Ignite 3

[Denis Garus]

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?

[Denis Garus]

Sorry, I forgot to point the link

1. https://github.com/apache/ignite/pull/8989

чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:

> 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?
>

[Andrey Kuznetsov]

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 <[hidden email]>:

> Sorry, I forgot to point the link
>
> 1. https://github.com/apache/ignite/pull/8989
>
> чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
>
> > 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.

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > Sorry, I forgot to point the link
> >
> > 1. https://github.com/apache/ignite/pull/8989
> >
> > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> >
> > > 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.
>

[Denis Garus]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > Sorry, I forgot to point the link
> > >
> > > 1. https://github.com/apache/ignite/pull/8989
> > >
> > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> > >
> > > > 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.
> >
>

[Alexei Scherbakov]

+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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > > > Sorry, I forgot to point the link
> > > >
> > > > 1. https://github.com/apache/ignite/pull/8989
> > > >
> > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> > > >
> > > > > 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

[Kseniya Romanova]

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 <[hidden email]
>:

> +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 <[hidden email]>:
>
> > 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 <[hidden email]
> >:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > Sorry, I forgot to point the link
> > > > >
> > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > >
> > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> > > > >
> > > > > > 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
>

[Valentin Kulichenko]

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 <[hidden email]>
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 <
> [hidden email]
> >:
>
> > +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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]
> > >:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>:
> > > > >
> > > > > > Sorry, I forgot to point the link
> > > > > >
> > > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > > >
> > > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> > > > > >
> > > > > > > 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
> >
>

[Denis Garus]

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 <
[hidden email]>:

> 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 <
> [hidden email]>
> 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 <
> > [hidden email]
> > >:
> >
> > > +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 <[hidden email]>:
> > >
> > > > 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 <
> > [hidden email]
> > > >:
> > > >
> > > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > Sorry, I forgot to point the link
> > > > > > >
> > > > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > > > >
> > > > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]>:
> > > > > > >
> > > > > > > > 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
> > >
> >
>

[Valentin Kulichenko]

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 <[hidden email]> 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 <
> [hidden email]>:
>
> > 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 <
> > [hidden email]>
> > 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 <
> > > [hidden email]
> > > >:
> > >
> > > > +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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > 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 <[hidden email]
> >:
> > > > > >
> > > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > Sorry, I forgot to point the link
> > > > > > > >
> > > > > > > > 1. https://github.com/apache/ignite/pull/8989
> > > > > > > >
> > > > > > > > чт, 8 апр. 2021 г. в 17:50, Denis Garus <[hidden email]
> >:
> > > > > > > >
> > > > > > > > > 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
> > > >
> > >
> >
>