Sixto Ortiz Jr., a journalist writing an article for Processor Magazine, pinged me with a set of questions on SOA Security. Here are the questions asked with answers – for the benefit of those who won’t get to read Processor Magazine.

1. What are the main security issues that can occur in an SOA environment?

The fundamental issue is one of authentication. This has two aspects:

1. Typically, within an organization, users are enabled to use specific applications or parts of applications. With SOA you no longer think in terms of applications but of services and end-to-end processes – and you build end-to-end processes. This means that the application security mechanisms that were in use prior to SOA are unlikely to work, because an end-to-end process is likely to involve multiple applications and each could have different user security mechanisms. In other words, the old security mechanisms are unlikely to work under SOA. The antidote to this problem is to implement a capable Identity Management system that has sophisticated provisioning capabilities.
2. With an ID Management system, users can be authenticated and have capabilities provisioned to them and this solves the first problem, but it doesn’t solve the “boundary problem”. The boundary problem occurs when one of your processes within your SOA wants to interact with a process in someone else’s SOA (could be another department or another company). Here we have a situation of software taking to software but each side must have a real (or implied) user behind it that has the authority to carry out certain activities.

Then you need to authenticate that:

• the software that you connect to really is the software you’re intending to connect to.
• that your user has the authority to make the connection and carry out the activities that the connection enables.
• that the other user you’re connecting to has the authority to connect to you.
• that the other software is only given the level of access that has been agreed.
• that everything happens according to a defined policy including disconnection and clean up.

2. What are some examples of potential problems?

As these issues are fundamentally about authentication the potential problems that can arise, if you don’t bring them under control are legion. For example; your users may do things they are not authorized to do in your systems or in another company’s systems, you may connect to rogue software which destroys data or commits a fraud, etc.

3. Why do these security issues occur in an SOA environment?

Put simply, the answer is:

1. Because current software environments never implemented a coherent authentication mechanism either for users or for software itself.
2. Because SOA integrates multiple software components from multiple environments and thus carves out paths of software activity that never previously existed and for which no security mechanisms are set up.

4. What security mechanisms do enterprises need to put in place to counter the security issues that could occur in an SOA environment?

As a basis they need

1. Identity management
2. Asset management and authentication for all software (including any software that is connected to outside the organization)
3. A system for exchanging security tokens which can act as credentials with other SOA domains.
4. Logs of user activity

5. What should administrators do in order to ensure security issues are addressed when developing their SOA infrastructures?

Implement security mechanisms using the technology described in 3. above. If this is not possible then, for the time being implement perimeter security around the SOA domain and allow no connections outside that domain. Also be sure to log all user activity.

6. Anything you’d like to add

This is not the whole story as, for example, it does not secure the environment against unauthorized use of computer resources or unauthorized access to specific data. Stirring those into the mix makes SOA security even more complex – however those are problems that exist with or without SOA.