Welcome to the jGuard's wiki » jGuard Documentation » Securing JMX remote access in webapps with jGuard

Securing JMX remote access in webapps with jGuard

Last modified by XWikiGuest on 2010/10/29 04:35

securing JMX remote access in webapps with jGuard

requirements

JMX is a great technology shipped with Java Standard Edition since java 5.

you will not have the ability to use it, if the JVM which runs your application server is lesser than java 5.

JMX is also shipped with j2ee 1.4 application servers, to expose some of their components.

what jGuard propose to enhance JMX security

  • unified security
jguard propose to control JMX remote access with the same underlying mechanism than local java access, for a better flexibility and security.

  • unified authentication
JMX authentication with jGuard only support login/pasword authentication challenge. other JMX authentications methods like CLIENT-CERT are planned.

  • unified authorization
Access control is only restricted if you activate the security manager .

this restriction is put by java implementation and not jGuard.

if you don't set the Security Manager, authenticated users will have access to ALL MBeans. if you set the Security Manager, you will have a fine-grained control on MBeans exposed.

these MBeans are protected with MBeanPermission. you will have read operation on them, restrict changes and so on...

these MBeanPermissions need to be registered in roles like any other permissions declared in jGuard. only users with roles containing MBeanPermissions will have access to them.

this powerful feature is unique, and only provided by jGuard.

activate JMX in you JVM

  • enable the JMX agent for local access
you have to set this system parameter when you start your application server:

-Dcom.sun.management.jmxremote
  • enable monitoring and management from remote systems
you have to set this system parameter when you start your application server:

-Dcom.sun.management.jmxremote.port=portNum

  • password protection for JMX access
password protection is enabled by default. you can define it explicitely with this system parameter:
-Dcom.sun.management.jmxremote.authenticate=true

  • activate JMX on a Windows operating system
TODO

activate JMX in your webapp

in your web.xml file, you have to insert this code:

<context-param>
	<param-name>enableJMX</param-name>
	<param-value>true</param-value>
</context-param>

optional jGuard JMX-related parameters

  • MBeanServer for connector
jguard guard access to Mbeans through a connector. you can define which MBeanServer will interact with the connector via the key mbeanServerForConnector.

    • if no one is defined or if the value is new, it will create a MBeanServer.
<context-param>
	<param-name>mbeanServerForConnector</param-name>
	<param-value>new</param-value>
</context-param>

    • if the value is position#N ,it will use the MBeanServer in the Nth position in the MBeanServer list returned by the MBeanServerFactory.
<context-param>
	<param-name>mbeanServerForConnector</param-name>
	<param-value>position#4</param-value>
</context-param>

    • if the value is MBeanServerName#N,it will use the MbeanServer in the Nth position among the MBeanServer list which has got this name returned by the MBeanServerFactory.
<context-param>
	<param-name>mbeanServerForConnector</param-name>
	<param-value>myMBeanServerName#0</param-value>
</context-param>

  • RMI Registry Host
you can define a custom RMI registry host via the key rmiRegistryHost in your web.xml file. if not specified, the default value is localhost

<context-param>
	<param-name>rmiRegistryHost</param-name>
	<param-value>192.168.0.5</param-value>
</context-param>

  • RMI registry Port
you can define a custom RMI registry port via the key rmiRegistryPort in your web.xml file. if not specified, the default value is 9005

<context-param>
	<param-name>rmiRegistryPort</param-name>
	<param-value>9016</param-value>
</context-param>

debug JMX remote access

JVM vendors provide a debug trace with the system parameter. it can have multiple values separated by a , .

accepted values

thi section is excerpted from chapter 1 of java Security published by O'Reilly editions:

  • all
Turn on all the debugging options.

  • access
Trace all calls to the checkPermission( ) method of the access controller. This allows you to see which permissions your code is requesting, which calls are succeeding, and which ones are failing.

This option has the following sub-options separated by a semi-colon (:). If no sub-option is specified, then all are in force:

  • stack
Dump the stack every time a permission is checked.

  • failure
Dump the stack only when a permission is denied.

  • domain
Dump the protection domain in force when a protection is checked.

  • jar
When processing a signed jar file, print the signatures in the file, their certificates, and the classes to which they apply.

  • policy
Print information about policy files as they are parsed, including their location in the filesystem, the permissions they grant, and the certificates they use for signed code.

  • scl
Print information about the permissions granted directly by a secure class loader (rather than granted through a policy file).

example

parameter with access option activated with the failure sub-option.

-Djava.security.debug=access:failure
parameter with scl and access
-Djava.security.debug=scl,access

important.png this facility should only used for debug purpose , because it will generate so many traces and will slow your application server.

how to reach the JMX connector Server

you can reach this connector securized by jguard at this url:

service:jmx:rmi://localhost/jndi/rmi://~~rmiRegistryHost~~:~~rmiRegistryPort~~/~~applicationName~~
Tags:
Created by diabolo512 on 2006/12/16 01:37

jGuard team copyright 2004-2009
3.1.1