Due to the implementation of the JMXConnectorServer, it is impossible to
intercept external calls to addNotificationListener to perform operations
such as security or auditing, without using a full-blown SecurityManager.
This is possible for every other call to JMX.

Also, JMX does not allow any security checks to be performed (or callbacks
to be invoked) upon emission of a notification, which means that dynamic
configuration changes to security will not be taken into account on existing
connections, and that notification forwarder services cannot know which
notifications can be securely delivered to which clients (since the connector
is hiding the client contexts).

###@###.### 2004-09-24

I see two solutions to this problem depending on the use of
a full-blown SecurityManager or not.

1) A SecurityManager is used.

   Currently the connector server implementation checks for:

   - an MBeanPermission("addNotificationListener") when
     the addNotificationListener() method is called.
   - an MBeanPermission("removeNotificationListener") when
     the removeNotificationListener() method is called.

   Perform an additional check for MBeanPermission("addNotificationListener")
   in the connector server before a new emitted notification is sent to an
   interested listener. If the policy object in use allows to change the
   access rights dynamically a given listener which had the right to register
   for notifications in the past may no longer have the right to receive
   them in the present according to the new access rights policy.

   A new property in the environment map will be introduced to enable/disable
   these new security checks. By default new security checks are not performed
   to keep existing behavior.

   Property name: "jmx.remote.x.check.notification.emission"
   Default value: "false"

2) No SecurityManager is in use. Customer-supplied access control.

   Define a new interface that will be called when the methods:

      - addNotificationListener()
      - removeNotificationListener()
      - fetchNotification() <called as many times as there are notifications
                             in the buffer that match the filters>

   get called by a JMX client.

   New class: com.sun.jmx.remote.security.NotificationAccessController

   New methods:

   void addNotificationListener(String connectionId,
                                ObjectName name,
                                Subject entity) throws SecurityException;

   void removeNotificationListener(String connectionId,
                                   ObjectName name,
                                   Subject entity) throws SecurityException;

   void fetchNotification(String connectionId,
                          Notification notification,
                          Subject entity) throws SecurityException;

   Property name: "jmx.remote.x.notification.access.controller"
   Default value: null

Solutions (1) and (2) are not exclusive and could be used at the same
time by a given connector server to define its access rights.

###@###.### 2005-2-18 16:05:22 GMT

I've just realised that this covers remote notifications but does not cover intra-agent notifications, which would require similar modifications to NotificationBroadcasterSupport - this is less a big issue since this is just a helper function and a different class can be implemented, but to extend JMX correctly, maybe there's a need for a SecureNotificationBroadcasterSupport or equivalent changes to NotificationBroadcasterSupport.

###@###.### 2005-3-11


###@###.### 2005-03-11 22:06:02 GMT