Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5106721

Ability to intercept addNotificationListener requests and outgoing notifications



    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 6
    • Component/s: core-svc
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      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


          Issue Links



              lmalvent Luis-Miguel Alventosa (Inactive)
              nstephen Nick Stephen (Inactive)
              0 Vote for this issue
              0 Start watching this issue