Hello, Maksim! Thanks for your analysis! I have a few questions about your proposals.
GridRestProcessor. AFAIK, when GridRestProcessor handle client request (GridRestProcessor#handleRequest) it process authentication (GridRestProcessor#authenticate) and then authorization of request (GridRestProcessor#authorize) inside client context. Can you give additional info about issues with GridRestProcessor from 3 and 4? Maybe you have a reproducer for the problem? NoOpIgniteSecurityProcessor. I think the case that you describe in 5 is not a bug. All nodes (client and server) must have security enabled or disabled. I can't imagine the case when it is not. ATTR_SECURITY_SUBJECT. I don't think that compatibility is needed here. If you will use node with propagation security context to remote node and older nodes you can get subtle errors. чт, 18 июл. 2019 г. в 11:12, Maksim Stepachev <maksim.stepac...@gmail.com>: > Hi, Ivan. > > Yes, I have. > https://issues.apache.org/jira/browse/IGNITE-11992 > > I'm waiting for a visa. > > > чт, 18 июл. 2019 г. в 11:09, Ivan Rakov <ivan.glu...@gmail.com>: > >> Hello Max, >> >> Thanks for your analysis! >> >> Have you created a JIRA issue for discovered defects? >> >> Best Regards, >> Ivan Rakov >> >> On 17.07.2019 17:08, Maksim Stepachev wrote: >> > Hello, Igniters. >> > >> > The main idea of the new security is propagation security context >> to >> > other nodes and does action with initial permission. The solution looks >> > fine but has imperfections. >> > >> > 1. ZookeaperDiscoveryImpl doesn't implement security into itself. >> > As a result: Caused by: class >> org.apache.ignite.spi.IgniteSpiException: >> > Security context isn't certain. >> > 2. The visor tasks lost permission. >> > The method VisorQueryUtils#scheduleQueryStart makes a new thread and >> loses >> > context. >> > 3. The GridRestProcessor does tasks outside "withContext" section. As >> > result context loses. >> > 4. The GridRestProcessor isn't client, we can't read security subject >> from >> > node attribute. >> > We should transmit secCtx for fake nodes and secSubjId for real. >> > 5. NoOpIgniteSecurityProcessor should include a disabled processor and >> > validate it too if it is not null. It is important for a client node. >> > For example: >> > Into IgniteKernal#securityProcessor method createComponent return a >> > GridSecurityProcessor. For server nodes are enabled, but for clients >> > aren't. The clients aren't able to pass validation for this reason. >> > >> > 6. ATTR_SECURITY_SUBJECT was removed. It broke compatibility. >> > >> > I going to fix it. >> > >> >
