From peter.gergely.horvath at gmail.com Mon Jun 11 13:14:04 2018 From: peter.gergely.horvath at gmail.com (=?UTF-8?Q?P=C3=A9ter_Gergely_Horv=C3=A1th?=) Date: Mon, 11 Jun 2018 15:14:04 +0200 Subject: jmx-dev Kerberos authentication for JMX? Message-ID: Hi All, I have been working with Big Data for a while and I have seen that a number of the components have started to have their own custom baked solutions (minimalistic Web UIs) for basic management operations, like showing metrics, debugging etc instead of using JMX. I have the feeling that getting JMX working for dozens of different Java services within a large cluster is an overly tough task, especially if you do not want to make compromises around security. For me it seems, that at the moment there is a gap between what the JDK offers regarding JMX monitoring/management and what people would need in a real world setting to use it effectively in an easy and secure way. I am wondering if it would be possible to implement a Kerberos-based authentication mechanism for JMX, allowing all services of a cluster to authenticate JMX clients against a centrally managed Kerberos service, that would also be officially supported by VisualVM so as to give an easy-to-use user interface. Based on my understanding, this could either be a new protocol implementation or assuming JDK-8171311: REST APIs for JMX gets done, an additional feature around there to support GSS Negotiate/SPNEGO based authentication. Could you please share your thoughts on this? Would anyone be interested to sponsor this topic? Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Jun 12 08:00:47 2018 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Jun 2018 11:00:47 +0300 Subject: jmx-dev Kerberos authentication for JMX? In-Reply-To: References: Message-ID: <2BA66DF8-9833-4D8A-A436-78AD36108065@gmail.com> Hi Peter, This is an issue for prod environments that is becoming bigger as clusters become bigger and bigger. I believe the answer to your issues and others related to the reliance of RMI has been proven by a project call Jolokia (https://jolokia.org ) which uses REST. At issue is that Jolokia is *not* a drop in JMXConnector replacement meaning you can?t use standard client tooling and this unfortunately compromises Jolokia?s usefulness. There is a JEP (http://openjdk.java.net/jeps/8171311 ) for providing a REST adaptor that unfortunately also misses the mark in that it?s not a JMXConnector. I?m not sure *why* these efforts have seemingly avoided the obvious solution which would be an REST based implementation of the JMXConnector interface as I believe that would be about the same about of work and would allow everyone to continue to use already available tooling. I have the task to prototype my own implementation running 2rd on my todo list right after I get my heap dump analysis tooling functional. So, yes, this is a real issue and I hope a discussion will lead to a more scalable solution. Kind regards, Kirk > On Jun 11, 2018, at 4:14 PM, P?ter Gergely Horv?th wrote: > > Hi All, > > I have been working with Big Data for a while and I have seen that a number of the components have started to have their own custom baked solutions (minimalistic Web UIs) for basic management operations, like showing metrics, debugging etc instead of using JMX. > > I have the feeling that getting JMX working for dozens of different Java services within a large cluster is an overly tough task, especially if you do not want to make compromises around security. For me it seems, that at the moment there is a gap between what the JDK offers regarding JMX monitoring/management and what people would need in a real world setting to use it effectively in an easy and secure way. > > I am wondering if it would be possible to implement a Kerberos-based authentication mechanism for JMX, allowing all services of a cluster to authenticate JMX clients against a centrally managed Kerberos service, that would also be officially supported by VisualVM so as to give an easy-to-use user interface. > > > Based on my understanding, this could either be a new protocol implementation or assuming JDK-8171311: REST APIs for JMX gets done, an additional feature around there to support GSS Negotiate/SPNEGO based authentication. > > Could you please share your thoughts on this? Would anyone be interested to sponsor this topic? > > Thanks, > Peter > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Jun 12 09:41:52 2018 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Jun 2018 15:11:52 +0530 Subject: jmx-dev Kerberos authentication for JMX? In-Reply-To: References: Message-ID: <51f09658-41ff-f83e-617a-18abf25413c8@oracle.com> Hi Peter, JMX agents support JAAS based authentication. The login module - Krb5LoginModule along with JAAS can be used to setup Kerberos-based authentication for JMX. A JAAS config file for Kerberos clients could look like, kerberosClient { ?????? com.sun.security.auth.module.Krb5LoginModule required ?????? debug=true ?????? useKeyTab=false ????? ........... }; where the configuration options for above login module can be found at, https://docs.oracle.com/javase/10/docs/api/com/sun/security/auth/module/Krb5LoginModule.html The default JMX agent can be started by setting below two system properties. 1. com.sun.management.jmxremote.login.config - The JAAS entry in config file above 2. java.security.auth.login.config - The path to the above file Example: java -Dcom.sun.management.jmxremote.port=5000 ???? -Dcom.sun.management.jmxremote.login.config=kerberosClient ???? -Djava.security.auth.login.config=kerberos.config ???? -jar MyApplication.jar I have not tried the steps above myself but should work in theory. Give it a try and let me know if it works. Thanks Harsha On Monday 11 June 2018 06:44 PM, P?ter Gergely Horv?th wrote: > Hi All, > > I have been working with Big Data for a while and I have seen that a > number of the components have started to have their own custom baked > solutions (minimalistic Web UIs) for basic management operations, like > showing metrics, debugging etc instead of using JMX. > > I have the feeling that getting JMX working for dozens of different > Java services within a large cluster is an overly tough task, > especially if you do not want to make compromises around security. For > me it seems, that at the moment there is a gap between what the JDK > offers regarding JMX monitoring/management and what people would need > in a real world setting to use iteffectively in an easy and secure way. > > I am wondering if it would be possible to implement a Kerberos-based > authentication mechanism for JMX, allowing all services of a cluster > to authenticate JMX clients against a centrally managed Kerberos > service, that would also be officially supported by VisualVM so as to > give an easy-to-use user interface. > > > Based on my understanding, this could either be a new protocol > implementation or assuming JDK-8171311: REST APIs for JMX gets done, > an additional feature around there to support GSS > Negotiate/SPNEGO?based authentication. > > Could you please share your thoughts on this? Would anyone be > interested to sponsor this topic? > > Thanks, > Peter > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 28 15:23:20 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:23:20 -0700 (PDT) Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: Resending the email after subscribing to HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net Thanks, Siba From: Sibabrata Sahoo Sent: Thursday, June 28, 2018 8:40 PM To: HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net; HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Jun 28 15:46:16 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Jun 2018 17:46:16 +0200 Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <3e4af336-6863-4145-9dce-60b08ea64a79@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> [ccing serviceability-dev at openjdk.java.net] Hi Siba, This looks good to me - but I'm not a SSL expert. It would be good to get someone from the security team eyeball those changes (Xuelei? Brad?) I added serviceability-dev at openjdk.java.net in cc as this is where reviews for JMX/Monitoring changes happen these days... best regards, -- daniel On 28/06/2018 17:10, Sibabrata Sahoo wrote: > Hi, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ > > Change: > > The Test has been upgraded to address the following 2 cases, > > 1. Add protocol support for TLSv1.3. The change is done in the config > file named ?management_ssltest11_ok.properties.in?. > 2. Add support for legacy TLS. Now a new config file > ?management_ssltest15_ok.properties.in? hold TLS protocol > ?TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA? instead > of ?SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5?. > > Previously the Test was using DSA keys which is not compatible with > TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the > instruction in ?Readme.txt? changed which generates RSA(2048 bit) keys. > > NOTE: Few Test was problem listed which are removed from the list now. > Mach 5 result PASS with multiple try for all 14 Test belongs to > ?open/test/jdk/sun/management/jmxremote? folder. > > Thanks, > > Siba > From sibabrata.sahoo at oracle.com Thu Jun 28 15:10:10 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:10:10 -0700 (PDT) Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Message-ID: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 28 15:15:44 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 28 Jun 2018 08:15:44 -0700 (PDT) Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <3e4af336-6863-4145-9dce-60b08ea64a79@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> Message-ID: <8e9e4472-cdc3-48a2-afd5-af310f4987a2@default> Hi Daniel, I am not a member of HYPERLINK "mailto:jmx-dev at openjdk.java.net"jmx-dev at openjdk.java.net. So the review posted is waiting for moderator's approval. Thanks, Siba From: Sibabrata Sahoo Sent: Thursday, June 28, 2018 8:40 PM To: jmx-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ Change: The Test has been upgraded to address the following 2 cases, Add protocol support for TLSv1.3. The change is done in the config file named "management_ssltest11_ok.properties.in". Add support for legacy TLS. Now a new config file "management_ssltest15_ok.properties.in" hold TLS protocol "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" instead of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". Previously the Test was using DSA keys which is not compatible with TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. NOTE: Few Test was problem listed which are removed from the list now. Mach 5 result PASS with multiple try for all 14 Test belongs to "open/test/jdk/sun/management/jmxremote" folder. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Fri Jun 29 08:22:20 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Fri, 29 Jun 2018 01:22:20 -0700 (PDT) Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> Message-ID: <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> May I get the approval from serviceability-dev at openjdk.java.net. Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Thursday, June 28, 2018 9:27 PM To: Daniel Fuchs ; Sibabrata Sahoo ; jmx-dev at openjdk.java.net; security-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure Hi Siba, The change looks fine to me. I would like Serviceability review this change as well. Thanks, Xuelei On 6/28/2018 8:46 AM, Daniel Fuchs wrote: > [ccing serviceability-dev at openjdk.java.net] > > Hi Siba, > > This looks good to me - but I'm not a SSL expert. > It would be good to get someone from the security team eyeball those > changes (Xuelei? Brad?) > > I added serviceability-dev at openjdk.java.net in cc as this is where > reviews for JMX/Monitoring changes happen these days... > > best regards, > > -- daniel > > On 28/06/2018 17:10, Sibabrata Sahoo wrote: >> Hi, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205653 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8205653/webrev.00/ >> >> Change: >> >> The Test has been upgraded to address the following 2 cases, >> >> ?1. Add protocol support for TLSv1.3. The change is done in the >> config >> ??? file named "management_ssltest11_ok.properties.in". >> ?2. Add support for legacy TLS. Now a new config file >> ??? "management_ssltest15_ok.properties.in" hold TLS protocol >> ??? "TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" >> instead >> ??? of "SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5". >> >> Previously the Test was using DSA keys which is not compatible with >> TLSv1.3. So the keys has been upgraded to use RSA(2048 bit). Hence >> the instruction in "Readme.txt" changed which generates RSA(2048 bit) keys. >> >> NOTE: Few Test was problem listed which are removed from the list now. >> Mach 5 result PASS with multiple try for all 14 Test belongs to >> "open/test/jdk/sun/management/jmxremote" folder. >> >> Thanks, >> >> Siba >> > From Alan.Bateman at oracle.com Fri Jun 29 08:32:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jun 2018 09:32:38 +0100 Subject: jmx-dev [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> Message-ID: <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com> On 29/06/2018 09:22, Sibabrata Sahoo wrote: > May I get the approval from serviceability-dev at openjdk.java.net. > This a test only change to update the keystores and the list of ciphers/protocols that the test uses. There's nothing serviceability specific here so having a Reviewer from the security area should be okay in the event that don't get a quick review on serviceability-dev list. -Alan