[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371655#comment-17371655 ] Alexey Gidaspov commented on IGNITE-14335: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > 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 > Fix For: 2.11 > > Time Spent: 6h 40m > 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)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337448#comment-17337448 ] Mikhail Petrov commented on IGNITE-14335: - [~nizhikov], [~garus.d.g], [~timonin.maksim] Thanks a lot for the review. > 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: 6h 40m > 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)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337442#comment-17337442 ] Ignite TC Bot commented on IGNITE-14335: {panel:title=Branch: [pull/8892/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} {panel:title=Branch: [pull/8892/head] Base: [master] : New Tests (3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1} {color:#8b}Cache 7{color} [[tests 2|https://ci.ignite.apache.org/viewLog.html?buildId=5988864]] * {color:#013220}IgniteCacheTestSuite7: AuthenticationConfigurationClusterTest.testBothAuthenticationAndSecurityPluginConfiguration - PASSED{color} * {color:#013220}IgniteCacheTestSuite7: AuthenticationProcessorSelfTest.testRemoteNodeSecurityContext - PASSED{color} {color:#8b}Java Client{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=5988821]] * {color:#013220}IgniteClientTestSuite: JettyRestProcessorAuthenticatorUserManagementAuthorizationTest.testUserManagementAuthorization - PASSED{color} {panel} [TeamCity *-- Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=5988904buildTypeId=IgniteTests24Java8_RunAll] > 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)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[ https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311298#comment-17311298 ] Denis Garus commented on IGNITE-14335: -- [~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)