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.
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
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.
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 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 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:
|
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 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 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; |