Hi, Alexei.
The ticket [1] describes the general problem for all thin client
authorizations. Its particular case is described in the mentioned in [1]
ticket [2] on the example of a JDBC client with the reproducer attached.
[1] https://issues.apache.org/jira/browse/IGNITE-12589
[2] https://issues.apache.org/jira/browse/IGNITE-12579
On 26.02.2020 11:47, Alexei Scherbakov wrote:
Denis Garus,
It is forbidden to remove any public IGNITE attribute without proper
deprecation steps.
I have read the thread and still do not clearly see the problem. The subject id
is not required to be a node id.
The referenced in the thread ticket [1] do not provide any reproducers.
Can you properly demonstrate a broken scenario ?
[1] https://issues.apache.org/jira/browse/IGNITE-12589
пт, 21 февр. 2020 г. в 13:35, Andrey Kuznetsov <stku...@gmail.com>:
Hi, guys!
The change suggested by Denis looks robust to me: it covers security
subject handling by all kinds of clients/nodes at once. As for
ATTR_SECURITY_SUBJECT_V2 attribute, it is really better to move it to
plugin implementations to support backward compatibility with peer nodes of
older versions. Obviously, cluster with security disabled will not suffer
from attribute removal. Ignite core should know nothing about the specific
way of security context propagation.
Denis, could you please create Jira issue for your change?
чт, 20 февр. 2020 г. в 17:01, Denis Garus <garus....@gmail.com>:
I just transmitted security subjects for rest requests.
SecurityContext has an unlimited size so we can get significant overhead.
And we do not solve problems with other thin clients.
If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between
old
versions and new.
I suggest removing ATTR_SECURITY_SUBJECT_V2 from Ignite's codebase, but
for
compatibility, it can be used by a security plugin like in PoC.
чт, 20 февр. 2020 г. в 16:47, Maksim Stepachev <
maksim.stepac...@gmail.com
:
Yes, I said about it at 07.19.
http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708
And in my solution, I just transmitted security subjects for rest
requests.
If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between
old
versions and new.
чт, 20 февр. 2020 г. в 15:56, Denis Garus <garus....@gmail.com>:
Hi, Igniters!
At present, a security subject id is assumed to be node id.
But when we are dealing with thin client, JDBC or REST subject id is
random
UUID. In this case, we cannot get the subject information on a remote
node,
and we get problems like these [1], [2].
To fix the problem, we should spread the client session to the whole
cluster.
I want to suggest a solution to the problem.
First, we should get subject information using GridSecurityProcessor.
How GridSecurityProcessor will retrieve a subject data, it is up to
plugin
developers.
Second, we should get rid of the assumption that a subject id is a
node
id
and remove the ATTR_SECURITY_SUBJECT_V2 attribute.
I have prepared PoC PR [3] that:
- places the existing logic of spreading security context to
GridSecurityProcessor;
- uses GridSecurityProcessor to get SecurityContext.
1.
http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html
2. https://issues.apache.org/jira/browse/IGNITE-12589
3. https://github.com/apache/ignite/pull/7375
--
Best regards,
Andrey Kuznetsov.
