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:
- Secure the communication channel between the application and the server.
- Authorizing the application to invoke the NotificationBroker.
- Authorizing the application to access the resources of the service integration bus.
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.
- Secure the communication between the application and the server:
- Provide security for inbound requests and associated responses by configuring the WS-Notification service point.
- For JAX-WS based Version 7.0 WS-Notification service points, attach security-enabled policy sets to the application associated with the service point. For JAX-RPC based Version 6.1 WS-Notification service points, configure security for the inbound ports associated with the service point.
- If we are using SOAP over HTTP as the binding for the WS-Notification service point, modify it to use SOAP over HTTPS as described in Configure secure access to WS-Notification service points by using SOAP over HTTPS.
- If we are using SOAP over JMS as the binding (for Version 6.1 WS-Notification services), configure the JMS connection factory used by the client application to use a secure communication protocol to communicate with the JMS provider. Exactly how you do this depends upon the JMS provider. For the service integration bus as the JMS provider, configure the client to use SSL to communicate with the server by setting the target inbound transport chain to InboundSecureMessaging as described in How JMS applications connect to a messaging engine on a bus and its related tasks.
- Provide security for outbound requests (for example notifications from the server to subscribed consumers) by configuring the WS-Notification service.
- For JAX-WS based Version 7.0 WS-Notification services, the steps involved are similar to those for applying security to JAX-WS web service clients except that any binding or configuration created is applied to the WS-Notification service. For more information, see Secure JAX-WS web services using message-level security.
- For JAX-RPC based Version 6.1 WS-Notification services, the steps involved are similar to those for applying security to service integration bus-enabled web services outbound ports except that any binding or configuration created is applied to the WS-Notification service. For more information, see Secure bus-enabled web services and its sub-topics, notably Invoking outbound services over HTTPS.
- We can also use WS-Security to sign or encrypt SOAP messages.
- For JAX-WS based Version 7.0 WS-Notification services, see Signing and encrypting message parts using policy sets.
- For JAX-RPC based Version 6.1 WS-Notification services, see Configure secure transmission of SOAP messages by using WS-Security.
- Authorize the application to invoke the NotificationBroker:
- 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.
- Configure the server to authorize the client application identity to carry out the required operations.
- For JAX-WS based Version 7.0 WS-Notification services, we can use Web services policy sets such as the "Username WS-I RSP default" or "Username WSSecurity default" policy sets to apply authorization to the Web services that are deployed in the enterprise application associated with a service point. See also the IBMdeveloperWorks article Configure JAX-WS applications with WS-Security for WS-Notification.
- For JAX-RPC based Version 6.1 WS-Notification services, we can apply authorization to the whole of an inbound service (for example the NotificationBroker endpoint of a WS-Notification service point) as described in Password-protecting inbound services, or configure authorization constraints independently for each Web service operation as described in Password-protecting a web service operation.
- Authorize the application to access the resources of the service integration bus.
- 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.
For general information about configuring access to the service integration bus, see Secure service integration.
- Authorize the application identity to be able to connect to the service integration bus, as described in Administer the bus connector role.
- 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.
- 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.
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