Hello, Igniters.
As of now, there are two independent APIs related to security:
1. IgniteSecurity - handle node/client authentication and authorize all
operations.
2. IgniteAuthenticationProcessor - handle authentication of thin clients
only.
The main purpose of creating the IgniteAuthenticationProcessor was to
bring default security implementation in Ignite (see [1]) because
IgniteSecurity has always had a single implementation that delegates
authorization and authentication operation to an external security plugin.
But two different APIs that are related to the same leads to security
checks duplication in code. As of now, it's possible to configure both
security approaches at the same time, and that is confusing for the
user. E.g., the user can provide a security plugin and execute ALTER /
DROP / CREATE commands successfully. In this case, mentioned commands
will do nothing because they only work with the authentication processor
I propose to merge the two mentioned above security APIs into one based
on the IgniteSecurity interface.
For this it is proposed:
1. Remove an IgniteAuthenticationProcessor that is now treated as an
independent processor.
2. Move the logic of IgniteAuthenticationProcessor into the
implementation of the security plugin that will be used if
authentication is enabled via configuration.
3. 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.
4. Remove the AuthorizationContext completely as IgniteSecurity provides
an API for storing and managing the security contexts.
5. 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:
   public void createUser(String login, UserOptions opts) throws
IgniteCheckedException  Â
�
   public void alterUser(String login, UserOptions opts) throws
IgniteCheckedException
      �
   public void dropUser(String login) throws IgniteCheckedException
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 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.
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 authentication
is disabled.
WDYT?
Ticket - https://issues.apache.org/jira/browse/IGNITE-14335
Draft PR - https://github.com/apache/ignite/pull/8892
[1] -
http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html
Regards,
Mikhail.
