How Will SOA Security Work?

One of the fundamental problems of SOA is “How do you make it secure?” And, if we’re going to be thorough about it, it’s really three questions:

1. How do you make SOA secure within the corporation?
2. How do you make SOA secure over the web?
3. How does SOA security work in a federated world?

Consultancy clients sometimes ask me how to get started on SOA. If they haven’t got ID Management properly deployed and/or they don’t have Asset Management properly squared away, I advise them to get those areas right ASAP.

Why? Because you can’t have SOA security without ID Management and you can’t have flexible provisioning without Asset Management.

I was briefed last week by CA on the new release of their Identity Management software portfolio - IAM. Aside from the usual set of user requests, interface changes and fixes that you have in the typical new release, the big change, from a marketing perspective, is that the component previously known as Transaction Minder is now called CA SOA Security Manager.

If you look at the details here you quickly discover that this is more than “marketecture”. Both Site Minder and Transaction Minder/CA SOA Security Manager have seen undergone significant enhancement. here’s a flash summary:

1. Technically a good deal of work has been done on federation, both to simplify implementation and expand deployment options (including the provision of a Federation Gateway with a Secure Proxy Server and support for mobile phones). There is now a Site Minder “federation end point”.
2. The CA Site Minder /CA SOA Security Manager combination is now truly policy driven with a policy engine, with Site Minder now including a dedicated policy engine, called policy analyzer. Among other things, this means that ID management policy can be centralized (even in a federated ID Management world) and regulatory compliance is easier to handle. (CA tells me that the average company has 35 to 40 different “compliance” initiatives/organizations that it needs to take note of).
3. The CA SOA Security Manager provides the basis for implementing SOA security “at the end-points” i.e. to satisfy security mandates when interacting with other internal systems, other organizations or, in fact, other software of any kind.

CA SOA Security Manager does not dictate how SOA security is implemented - a variety of different strategies is possible and there are environmental dependencies anyway. What it provides is a SOA Security Gateway which enables security services to be applied to Web Services calls within or outside the organization. It also provides a SOA security agent for Web Service containers.

Ultimately the point of all this is that SOA delivers you end-to-end business processes that can span the corporate network and reach outside it - perhaps being initiated outside and involving processes or services from business partners.

The SOA security conundrum is simply that security has to be end-to-end, a chain being only as strong as its weakest link. It thus needs a capability similar to the one that CA now provides - for all business processes, whether internal, partly external or partly external and federated across multiple disparate environments.