[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311298#comment-17311298 ]
Denis Garus edited comment on IGNITE-14335 at 3/30/21, 9:05 AM: ---------------------------------------------------------------- [~PetrovMikhail] Suggested realization provides a security plugin when {{isAuthenticationEnabled}} is {{true}} and, in this way, makes {{IgniteSecurity}} enabled. But current implementation of {{IgniteAuthenticationProcessor}} (security plugin) does not allow: * apply a security policy, so authorization does not make sense * authenticate clients, except SQL clients * get the actual security context by a security subject id. Another hand, security-enabled mode adds to every communication message a security subject id, makes a security context switch, authorizes an operation, and so on that is a waste of resources. Thus, let's implement a worthy default security plugin or choose another way to realize this task. was (Author: garus.d.g): [~PetrovMikhail] Suggested realization provides a security plugin when {{isAuthenticationEnabled}} is {{true}} and, in this way, makes {{IgniteSecurity}} enabled. But current implementation of {{IgniteAuthenticationProcessor}} (security plugin) does not allow: * apply a security policy, so authorization does not make sense * authenticate clients, except SQL clients * get the actual security context by a security subject id. Another hand, security-enabled mode adds to every communication message a security subject id, makes a security context switch, authorizes an operation, and so on that is a waste of resources. Thus, let's implement a worthy default security plugin or choose another way to realize this task. > 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)