Some observations regarding SOA security

IASA meeting, November 17, 2006

Dr. Craig Miller spoke about Service Oriented Architecture (SOA) and software security. He began by making some general observations, pointing out that the distributed applications in the eighties, were similar to SOA.

Miller said he had been an early advocate of web services, having persuaded his previous employer, Proxicom, to offer web services.

Miller emphasized that security is a fundamental attribute of an application, not something you add on to an application software after you have finished building it.

He said that SOA can be defined in terms of technology or in terms of architecture. Currently, Gartner has a chart that shows SOA at its the height of its curve of adoption, suggesting that a crash is imminent. Miller said that this was probably true of SOA as a technology, but that SOA as an architectural topology is inevitable.

Here, Miller gave an outline of the history of IT architecture:
1) unconnected systems
2) spaghetti architecture -- point to point connectivity
3) hub and spoke -- data warehouse at the center
4) data bus -- moving data around with technologies like EAI
5) application bus -- SOA: robust standards

Miller described SOA as a continuing initiative; no one builds an organization around it.

SOA can be understood as a bunch of web services with a bus providing connectivity. Each web service does something small (such as extract the balance of an account); the application orchestrates the services through business logic.

Miller predicted that the web services part of this will be outsourced, with the bus and process logic done locally, because that is the more agile approach.

In a SOA system, the points of connectivity are points of vulnerability. Here, Miller said that software breaks more than anything else, that “crap” is the technical term.

Miller outlined the principles of network architecture as opposed to application software:
- componentization
- standardization - interface is rigid
- management (monitoring)

Here, a member of the audience pointed out that network software is simpler than application software. Miller agreed that this is true, but that network software offers lessons for applications software.

Miller said currently we don’t manage monitoring well in application software and that SOA facilitates monitoring by watching how often the bus calls for which web service and how the web service is used.

He said the industry has gotten over the point where everybody thought they could own the universe; we are now getting vendor independent standards. Here, he showed a diagram representing SOA structure:

client
presentation
logic
infrastructure
service

Miller said SOA succeeds because of the business imperative. With the Internet we already have ubiquitous connectivity. The Internet has also pushed us towards vendor independent standards.

The essential vulnerability in SOA is all the points of connection (between the individual web services, the bus, and the application).

Here, Miller offered a brief survey of the different approaches to security by the two standards organizations: W3C and OASIS.

W3C key web services security standards:

infrastructure:
XKMS
XML

requirements:
multipole security token format
trust format
signature formats
encryption technologies
end to end messaging

XML access control markup language:
encode XML rules for access
chief standards issue is many
tree of entities -> rules for access

Miller said XRML syntax has been described, but that he has not seen it implemented.

Individual web services can put limits on the way that they are invoked by means of message tokens.

Miller was enthusiastic about the SAML tool kit, saying that it allows you to do virtually anything.

The OASIS view of security: identification & authentication, data integrity, and data confidentiality.

Miller said that message uniqueness is profound in SOA; how do you know you haven’t seen this message before? For example, you could send a message, “give me $100” and then keep repeating that message. The software has to know it has already received the message. The insertion of a nonce is one way to address this.

Miller was emphatic that SOA does not obviate the need for software security. Here, he offered another slide illustrating the reality of SOA architecture:

client
presentation
osc bss orchestrate bs
the bus
web service/ web service/ BULA (big ugly legacy application)

He made the point that most SOA systems involve Big Ugly Legacy Applications. Loops that go past the bus, usually tying Big Ugly Legacy Applications to the system, are vulnerabilities. I asked if the value of web services is not precisely because they glue together big ugly legacy applications. Miller agreed that this was so.

Miller said that the things that make code ugly are bug fixes; clean code is code that has not been debugged

Miller listed the factors driving emerging technology as bandwidth, processor speed, memory (RAM), and storage media. He pointed out that his digital camera has a 128 MB flash card. He also said that distributed storage technology was the most unexploited technology.

Note - in an email sent after the presentation, Miller said, “Web service security can be enforced in two ways -- the infrastructure can enforce rules for publication and subscription, or individual services can enforce security based on message tokens. Both can be useful. From the perspective of elegant design, I like to embed the security in the infrastructure / messaging layer rather than leaving it to the author of the individual service. It is easier to monitor it there, and I firmly believe that monitoring is a fundamental aspect of web service security.”