 |
|
|
|
|
Though it uses some of the same technologies used in Web services, ... SOA is independent of any platform or communications protocol.
|
|
|
|
|
|
|
|
|
|
As interest in service-oriented architecture (SOA) has grown at financial firms, so have concerns about its security. SOA is at the cutting edge of IT services for financial businesses. But its very strength -- its ability to knit together disparate systems into a single service -- is also its weakness from a security perspective.
Defining SOA
SOA is an application architecture for packaging business processes as services. Unlike a traditional networked or distributed system where communication is tied to specific platforms or technologies, SOA is platform-independent.
SOA consists of a description language that loosely ties together the operating systems and programming languages behind applications. The description language defines how the services communicate with each other and pass data through the system.
SOA is frequently compared to Web services, which also link disparate systems, platforms and applications. Though it uses some of the same technologies used in Web services, like extensible markup language (XML) and Simple Object Access Protocol (SOAP), SOA is independent of any platform or communications protocol and doesn't necessarily have to be Web-based, as are Web services
SOA security
SOA security should be considered on three levels:
Level one: Securing the components that make up the SOA system
There are four general rules for server and workstation security: adequate access controls, up-to-date patches, and anti-malware protection and firewall protection. All rules are important, but apply in differing degrees to different types of systems. The focus on mainframe systems, for example, will be mostly on access controls, while the concern for distributed systems will be malware and firewall protection, in addition to access controls. And for all systems, keeping patches up to date is always key.
Level two: Consistently managing the identities of system users
This level is the most difficult and fundamental problem for SOA. For a SOA system to operate properly, each user has to be able to authenticate to one component but at the same time, be able to authenticate and then communicate with other components of the system. Each component of the SOA system requires its own authentication and has its own users.
At first glance, it might appear that using single sign-on (SSO) to tie all the users together would do the trick. But since SOA is a service layer hiding the underlying technologies and systems that sit above all of these components, SSO won't work.
Since users have to be able to access different systems at different times, the SOA system -- not the individual components -- has to be the one holding their identity. To do this, SOA uses identity propagation, which replicates authenticated identities through multiple business systems and processes. This is where federated identity management comes in. Federated identity management is based on universally accepted standards for authentication between systems and services.
Federated identity management is similar to SSO, except that SSO allows authentication once to multiple systems within an enterprise, while federated identity management allows the same but across systems in multiple enterprises. Ultimately, SOA is not just about using services within one enterprise but about the exchange of business services across different companies, like vendors and their partners.
The universally accepted standards, then, from federated identity management used for SOA include the Security Assertion Markup Language (SAML) and WS-Federation Language. These languages use XML to exchange authentication and authorization for SOA systems. They use various systems for exchanging authentication information within in SOA, including session keys, tokens, Kerberos tickets and digital certificates.
The idea is that these standards are supposed to be vendor-neutral to allow for interoperability of authentication between systems. But these standards are still at different levels of evolution and universal vendor acceptance.
Level three: Securing the connections between these same components
This includes securing not only the unified authentication credentials established by SAML or WS-Federation, but also the data moving between the systems. Since XML plays a big role in these standards, securing XML transmissions also plays a big part in SOA security. There are two parts to the security of XML transport: infrastructure security and encryption.
Encryption includes encrypting data in XML files being used by an SOA system. There are two World Wide Web Consortium specifications for encrypting and digitally signing XML files: XML-Encryption and XML-Signature. For XML files sent over HTTP connections, SSL should always be used to protect confidentiality of the transmission.
As for infrastructure security, hardware firewalls and security appliances can be used to protect the network traffic, internal or otherwise, which SOA systems inevitably use. But they'll need to be configured to allow XML messages, whether encrypted, digitally signed or possessing other security tokens for SOA to work properly across gateways and network boundaries.
SOA security is an extremely complex topic on many levels -- applications, hardware, standards and identity management. But this brief introduction should give an idea of what goes into securing an SOA system.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and the author of The Little Black Book of Computer Security available on Amazon. He also hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
