Secure service integration

Messaging security protects a service integration bus from unauthorized access. When admin security is enabled for the appserver, by default messaging security is also enabled for the bus. We can also manually administer messaging security for the bus. Review the security requirements for the bus. For guidance, see Service integration security planning.

New feature: In this release, the procedure to administer role-based authorization for service integration security is simplified by the introduction of a number of new and updated admin console panels Providing admin security is also enabled, messaging security enforces a security policy that prevents unauthorized client applications from connecting to the bus, bus resources. There might be circumstances when you do not require messaging security, for example on a development system. In this case, we can disable messaging security. We can customize the security configuration for the bus by using the admin console, or wsadmin scripting commands. The security configuration controls the following aspects of bus security:

• Authorizing groups of users in the user registry to undertake selected operations on bus destinations.

• The transport policies that maintain the integrity of messages in transit on the bus.

• The use of global, and multiple custom security domains.

• The integrity of links between messaging engines, foreign buses and databases.

Use the following tasks to administer messaging security:

 

Next steps

•  
  
  Secure buses

  Secure a service integration bus provides the bus with an authorization policy to prevent unauthorized users from gaining access. If a bus is configured to use multiple security domains, the bus also has a security domain and user realm to further enforce its authorization policy.

•  
  
  Disabling bus security

  If you do not require messaging security, we can choose to disable messaging security. Any new buses added after messaging is disabled are not secured.

•  
  
  Enable client SSL authentication

  Configure a service integration bus to allow connecting client JMS applications to authenticate by using SSL certificates.

•  
  
  Add unique names to the bus authorization policy

  How to update the authorization policy for the service integration bus with unique name entries.

•  
  
  Administer authorization permissions

  Service integration messaging 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 its resources when messaging security is enabled.

•  
  
  Administer permitted transports for a bus

  Use these tasks to configure a transport policy for a service integration bus, and to administer the transports chains that remote applications clients can use to connect to a service integration bus.

•  
  
  Secure messages between messaging buses

  Use these tasks to administer the access control security associated with sending messages between buses.

•  
  
  Secure access to a foreign bus

  We can secure the link between a local bus and a foreign bus.

•  
  
  Secure links between messaging engines

  For a mixed-version bus, when security is enabled, you must define an inter-engine authentication alias so that the messaging engines can establish trust.

•  
  
  Controlling which foreign buses can link to the bus

  Use this task to control which foreign buses are allowed to link to the bus.

•  
  
  Secure database access

  We can protect the data store from access by unauthorized users.

•  
  
  Secure mediations

  Use the following tasks to secure mediations at an operations level. For example, a mediation inherits its identity from a the messaging engine, but we might want to specify an alternative identity for the mediation to use.

   

---

Last updated Nov 10, 2010 8:23:07 PM CST