Hi I'm Vincent a new contributor on JGuard,
I'm working on securing JMX connections with jGuard. I created this topic to have your thoughts about the way JMX should be enabled.
In the JGuard branch v070_standalone I'm working on, we organized the Configuration and Policy installation differently.
In 0.7 version, the configuration and the policy were installed in AccessFilter and removed
in contextDestroyed of ContextListener. This was not very logical and forced people to
use AccessFilter even if they only wanted to use JGuard to secure JMX connection. Therefore,
we proposed to move the configuration and the policy initialisation into the method
contextInitialized from net.sf.jguard.listeners.ContextListener. In this branch, ContextListener is now
used to load and unload Configuration and Policy and AccessFilter is only dedicated to filtering.
The actions to be done to enable JMX in JGuard are to start a JMX server and attach to it
an authenticator that will log in using JGuard configuration.
We see two ways to enable JMX for JGuard users:
- use ContextListener and a flag : in ContextListener.contextInitialized(...) when the Configuration and
the Policy are installed, we perform JMX initialization if a flag is defined in web.xml :
web.xml example :
<web-app>
....
<context-param>
<param-name>enableJMX</param-name>
<param-value>true</param-value>
</context-param>
<listener>
<listener-class>
net.sf.jguard.listeners.ContextListener
</listener-class>
</listener>
...
</web-app>
- The second way to enable JMX is to create a second ServletContextListener starting JMX :
<web-app>
....
<listener>
<listener-class>
net.sf.jguard.listeners.ContextListener
</listener-class>
</listener>
<listener>
<listener-class>
net.sf.jguard.listeners.JMXListener
</listener-class>
</listener>
...
</web-app>
What do you think is the best ?
This post introduces the major changes so if there are unclear explanations, don't hesitate to ask me.
Bye,
Vincent Beretti
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm from France.
Here are the reasons why we thought it could be better to put a flag in the contextListener :
- If you secure JMX connection, you have to install JGuard Policy, so if it is declared separatly, ContextListener may be forgotten by the user configuring JGuard.
- It minimizes the configuration : only one listener to configure with some properties and flags.
- ContextListener must be started before JMXListener. So configuring the two listeners may add potential errors if the user declares it the wrong way whereas with the flag, the code takes care of the starting order (first Policy installation, then securing JMX)
What do you think ?
See you,
Vincent Beretti
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi I'm Vincent a new contributor on JGuard,
I'm working on securing JMX connections with jGuard. I created this topic to have your thoughts about the way JMX should be enabled.
In the JGuard branch v070_standalone I'm working on, we organized the Configuration and Policy installation differently.
In 0.7 version, the configuration and the policy were installed in AccessFilter and removed
in contextDestroyed of ContextListener. This was not very logical and forced people to
use AccessFilter even if they only wanted to use JGuard to secure JMX connection. Therefore,
we proposed to move the configuration and the policy initialisation into the method
contextInitialized from net.sf.jguard.listeners.ContextListener. In this branch, ContextListener is now
used to load and unload Configuration and Policy and AccessFilter is only dedicated to filtering.
The actions to be done to enable JMX in JGuard are to start a JMX server and attach to it
an authenticator that will log in using JGuard configuration.
We see two ways to enable JMX for JGuard users:
- use ContextListener and a flag : in ContextListener.contextInitialized(...) when the Configuration and
the Policy are installed, we perform JMX initialization if a flag is defined in web.xml :
web.xml example :
<web-app>
....
<context-param>
<param-name>enableJMX</param-name>
<param-value>true</param-value>
</context-param>
<listener>
<listener-class>
net.sf.jguard.listeners.ContextListener
</listener-class>
</listener>
...
</web-app>
- The second way to enable JMX is to create a second ServletContextListener starting JMX :
<web-app>
....
<listener>
<listener-class>
net.sf.jguard.listeners.ContextListener
</listener-class>
</listener>
<listener>
<listener-class>
net.sf.jguard.listeners.JMXListener
</listener-class>
</listener>
...
</web-app>
What do you think is the best ?
This post introduces the major changes so if there are unclear explanations, don't hesitate to ask me.
Bye,
Vincent Beretti
Hi Vincent,
I like more the second option: is more explicit.
Where are you from?
[]'s
Vinícius Pitta Lima de Araújo
from Brazil
Hi,
I'm from France.
Here are the reasons why we thought it could be better to put a flag in the contextListener :
- If you secure JMX connection, you have to install JGuard Policy, so if it is declared separatly, ContextListener may be forgotten by the user configuring JGuard.
- It minimizes the configuration : only one listener to configure with some properties and flags.
- ContextListener must be started before JMXListener. So configuring the two listeners may add potential errors if the user declares it the wrong way whereas with the flag, the code takes care of the starting order (first Policy installation, then securing JMX)
What do you think ?
See you,
Vincent Beretti
I can't disagree with you because you show me so many reasons to use the flag option. :)
When I sugested use the ContextListener I was thinking in 'beautifull' and 'an easy way to read'.
[]'s
Vinícius Pitta Lima de Araújo