In the old management team, we have been considering the idea of getting rid of jmx connection in gfsh and only using http connection mechanism.
On Jun 19, 2020 2:53 PM, Jacob Barrett <jabarr...@vmware.com> wrote: So I can see why this research paper was so bleak about the options in trying to get the SSL certificate for the current connection being serviced. As they discovered the accept loop in OpenJDK’s (and older Oracle implementations) immediately fires the RMI operation to a thread pool after connected. This is after SSLSocket would have would’ve done the handshake and been passed to any of our validation callbacks so stashing anything in a thread local storage is dead. Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is a ThreadLocal<ConnectionHandler> that has the socket used to establish the connection and this thread local is set before each invocation of an RMI operation. The bad news is that it's private on an internal class. I think this is where the age of the research is in our favor. Back when I think it was writing we didn’t have OpenJDK. We had Oracle, IBM, and a few others. Now with everything pretty much converging on OpenJDK I don’t believe it as as nasty to go poke at this internal using reflection. I think it is less dirty then their nasty trick of utilizing the IPv6 address as a unique identifier in a custom Socket. Once we have the SSLSocket for this connection then we are golden. From there you have public API access to the SSLSession. Looking at the OpenJDK source this class has largely been unchanged since its initial import into the repo in 2007. Most importantly the private member in question has been and its sill available in all versions of OpenJDK. Sure this limits us to OpenJDK support for certificate based authentication by SSL handshake via RMI but in Geode that’s really only gfsh. This is a really small surface area. With the focus being on converting gfsh activities into REST APIs this surface area is shrinking. Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK. -Jake > On Jun 19, 2020, at 11:14 AM, Jacob Barrett <jabarr...@vmware.com> wrote: > > > >> >> On Jun 18, 2020, at 4:24 AM, Jakov Varenina >> <jakov.varen...@est.tech<mailto:jakov.varen...@est.tech>> wrote: >> >> In order to completely remove the need for username/password, it is required >> that we implement this new kind of authorization on *all* geode >> interfaces/components (cluster, gateway, web, jmx, locator, server). The >> reason why we didn't have any progress is because we faced major obstacle >> during development when we tried to retrieve clients certificate from RMI >> connections (e.g. jmx connections). It seems there are no easy/nice way to >> retrieve it, and what we came up so far is following: >> >> 1) We have found some possible "hack solution" that could be implemented and >> it is described in the following paper >> (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjiliao%40vmware.com%7C047d1b26112f4948b0ab08d8149b3ad3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004228769823&sdata=6fB1iM1Dk%2BJ%2B8oCHankNhd4%2FSd5EwKcxZlex%2BTcUg8U%3D&reserved=0). >> We have started to work on the prototype that will implement this solution. > > Wow, that is a hack. Have you found any implementation of this solution. > There doesn’t appear to be a repository listed. There also doesn’t appear to > be a publish date on this document. The most recent references are from 2010. > I wonder if things are better now. I am going to poke at the Java source code > a bit and report back. > > Would your needs be dependent on Java 8? If we found a solution that only > worked say with java 12, would that work? > > -Jake >
