[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-14335:
------------------------------------
Description:
It is proposed:
# Remove an IgniteAuthenticationProcessor that is now treated as an
independent processor.
# Move the logic of IgniteAuthenticationProcessor into the implementation of
the security plugin that will be used if authentication is enabled via
configuration.
# Remove duplication of security checks and leave IgniteSecurity as a single
security API. As of now, authentication operations are not delegated to
IgniteAuthenticationProcessor if a security plugin is specified. So the overall
security behavior from the user side will remain intact.
# Remove the AuthorizationContext completely as IgniteSecurity provides an API
for storing and managing the security contexts.
# Extend GridSecurityPlugin interface with methods that provide the ability to
manage security users to support existing commands available for authentication
processor - alter/drop/create through SQL and REST.
As a result, we will make the security-related code more consistent and simpler.
Proposed signatures of GridSecurityPlugin methods that provide the ability to
manage security users:
{code:java}
public void createUser(String login, UserOptions opts) throws
IgniteCheckedException {code}
{code:java}
public void alterUser(String login, UserOptions opts) throws
IgniteCheckedException{code}
{code:java}
public void dropUser(String login) throws IgniteCheckedException{code}
The UserOptions class is a wrapper over EnumMap that maps option values to
their aliases. This allows the class to be used for both create and alter user
operations and doesn't break backward compatibility in case new options are
declared.
The proposed changes lead to the following compatibility issues:
1. When a user provides a security plugin and enables native authentication -
in this case, the user will face exceptions during the node start while now
node starts smoothly. This case makes a little sense because now authentication
operations are not delegated to IgniteAuthenticationProcessor at all if a
security plugin is specified.
2. The current implementation of IgniteAuthenticationProcessor can enable
authentication itself if the current node connects to the cluster with
authentication enabled - this functionality will not be supported. The user can
easily overcome this by explicitly enabling authentication in the configuration
on all nodes.3. The error message of some mutually exclusive events can be
changed.
The remaining implementation of the IgniteAuthenticationProcessor and its
general behavior will remain intact. I also propose to keep the current
callbacks for the IgniteAuthenticationProcessor (e.g.
IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from other
managers intact, just skip these calls if the IgniteAuthenticationProcessor is
not being used for security.
was:
It's proposed to:
1. Make an IgniteAuthenticationProcessor implement GridSecurityProcessor
interface.
2. Remove duplication of security checks and leave IgniteSecurity as a single
security API.
3. Remove the AuthorizationContext completely as IgniteSecurity provides an API
for storing and managing the security contexts.
4. Extend GridSecurityPlugin interface with methods that provide ability to
manage security users to support existing commands available for authentication
processor - alter/drop/create through SQL and REST.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
> ----------------------------------------------------------------
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mikhail Petrov
> Assignee: Mikhail Petrov
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
