Securing Web messaging enabled applications

There are two different aspects to configuration a Web messaging enabled application: protecting the incoming URI and configuring client authentication and authorization to the service integraton bus.

Protecting a Web messaging URI

Depending on the type of Web messaging application you are writing, you might want to restrict access to a Web messaging URI. Web messaging URI's can be protected using standard Web application security methods. When a Web messaging URI is protected, the Bayeux handshake request will be authenticated and authorized using normal Web application security methods. Refer to the following topic: Securing applications during assembly and deployment section for more information. When application security is enabled, it is typical to enable transport security. The Web messaging service shares Web container transport chains and if you enable the Web messaging service on a secured transport chain , communication will be secured for all Bayeux operations.

Service integration bus authentication and authorization

When configuring a Web messaging enabled application with security enabled it is important to understand that the security requirements should be extended to the service integration bus interactions unless there is a specific reason for not doing so When planning your security model you should consider each of the aspects of security on the service integration bus described below. Refer to the following topic: Learning about service integration security for more information. When Web messaging clients connect to a secured service integration bus, the client must be authenticated and authorized to access service integration bus resources.

A Web messaging client must provide credentials to authenticate to a secured service integration bus. There are two options for methods for providing credentials: JavaTM 2 Connector authentication alias or Web credentials. The optimal method to use depends on the needs of the application. The authType and authAlias Web messaging configuration options specify which type to use. Refer to the Service integration bus configuration topic for detailed configuration information.

Java 2 Connector authentication alias

 A Java 2 Connector authentication alias is one method to allow Web messaging clients to authenticate to the service integration bus. An authentication alias should be used in the following situations:

  • Web security is disable and bus security is enabled. Specifying an authentication alias is the only possible solution for allowing Web messaging clients to access the service integration bus.
  • It is permissible for all Web messaging clients that come in on a single URI to have the same service integration bus topic space and topic permissions. In this case, it is easier to manage the authorization permissions for a single authentication instance than managing permissions for every authenticated Web user.
Web credentials When web security is enabled, Web credentials can be used as authentication information for connecting to a secure service integration bus. Basic authentication and LTPA single sign on cookies are the two supported Web credential types supported. You should set your Web messaging configuration file to use an authType of basic or sso under the following conditions:
  • Web security is enabled. Either basic auth or LTPA cookie information must readable in the HTTP request. If this information is unavailable, then access to a secure service integration bus will fail. The ability to read Web credentials is likely limited when a Trust association interceptor is in use. In that case you will be limited to using Java 2 Connector authentication alias.
  • Fine grained Web messaging user topic space or topic authorizations are required. In this case, you will have to follow the authorizaton steps below to allow user or group access to service integraton bus resources.

   

The service integration bus provides a series of security checks that allow authorization to be validated at a variety of granularities. The following authorization levels must be met for any authentication data specified.

Bus connector authorization The first level of authorization required in order to access a service integration bus is the ability to connect to the bus, or the bus connector authorization. Like other authorizations it is possible to grant this access to individual users, or to a group of users. Details on how to configure authorization for the bus connector role can be found in the Administering bus connector roles topic.
Topic space (destination) security Once an application has passed the bus connector authorization check the next thing it will need to do is access a destination. In the case of Bayeaux applications this will be the topic space destination (or destinations) specified in the Bayeaux configuration or channel name.

Each destinations has a set of individual roles associated with it that control the exact type of action that a particular application or user can carry out. For Bayeaux applications the most common roles of interest are the Receiver role to enable the application to create subscriptions and receive events, and the Sender role for publishing events to the topic space. Details on how to configure these authorization roles for a given topic space can be found in the following Destination security topic.

Topic security Within a topic space it is also possible to configure fine grained access control over individual topics or branches of topics. This means that one application can be prevented from seeing the events published on other topics by a different application, even if those events are being published in the same topic space.

Details on how to configure topic level security can be found in the following topics;



Terms of Use | Feedback