[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337177#comment-17337177 ]
Nikolay Izhikov commented on IGNITE-14335: ------------------------------------------ LGTM > 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: 6.5h > 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)