[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:#00008b}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:#00008b}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=5988904&buildTypeId=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)
