+

Search Tips   |   Advanced Search

Secure WS-Notification

The WS-Notification security implementation requires that a user identity is flowed in requests for WS-Notification services. This identity is used to authenticate the client application and check that the client is authorized to invoke the requested operation, and to access the underlying service integration bus topic spaces and topic resources.

WS-Notification uses the same mechanisms as other Web services to provide an authenticated identity. For example WS-Security or HTTP Basic Authentication.

There are three parts to configuring secure access to WS-Notification:

If messaging security is enabled, and the WS-Security or HTTP Basic Authentication components are not configured to flow a user identity in WS-Notification requests, then all such requests are treated as unauthenticated and can only access messaging resources that are accessible by the WAS "everyone" group.

  1. Secure the communication between the application and the server:

    1. Provide security for inbound requests and associated responses by configuring the WS-Notification service point.

    2. Provide security for outbound requests (for example notifications from the server to subscribed consumers) by configuring the WS-Notification service.

    3. We can also use WS-Security to sign or encrypt SOAP messages.

  2. Authorize the application to invoke the NotificationBroker:

    1. Configure the client application to provide an appropriate identity.

      To authorize a web service application to communicate with the server, the application must identify itself as running as a particular authenticated identity. The mechanism for doing this depends upon the type of web service binding you are using:

      • If we are using SOAP over HTTP web service bindings, use either HTTP Basic Authentication or WS-Security to provide the authenticated identity.

      • If we are using SOAP over JMS web service bindings (for Version 6.1 WS-Notification services), use WS-Security to provide an authenticated identity.

    2. Configure the server to authorize the client application identity to carry out the required operations.

  3. Authorize the application to access the resources of the service integration bus.
  4. Service integration bus security uses role-based authorization. When a user is assigned to a role, the user is granted all of the permissions that the role contains. By administering authorization permissions, we can control user access to a bus and to its resources when messaging security is enabled.

    1. Authorize the application identity to be able to connect to the service integration bus, as described in Administer the bus connector role.

    2. When the application can connect to the bus, grant the application access to the appropriate destinations on the bus.

      We can determine which service integration bus topic spaces are required, by checking which WS-Notification topic namespaces are used by the application then looking at the appropriate WS-Notification permanent topic namespace to find the service integration bus topic space to which it maps. We can then grant authorization (for example the Sender or Receiver roles) for the authenticated identity to access that topic space as described in Administer destination roles.

    3. After the client application has been authorized to access the appropriate topic space destination, you might also need to authorize the client application to access the individual topics within the topic space destination as described in Administer topic roles.
    For general information about configuring access to the service integration bus, see Secure service integration.


Related concepts

  • WS-Notification


    Related tasks

  • Use WS-Notification for publish and subscribe messaging for web services

  • WS-Notification troubleshooting tips
  • Configure JAX-WS applications with WS-Security for WS-Notification