Security is the one topic that's been conspicuously absent from the bulk of SOA articles, blog posts and discussions.
But that's changing - and rightly so, especially when you stop to consider the security implications of an architecture that can integrate systems and spread services - and the code that creates them - throughout the enterprise.
This week, ZapThink published a white paper, "SOA Security: Centralize & Integrate." Essentially, it's a case study about systems integrator SAIC's SOA implementation for an oil and gas company. As part of the project, SAIC created an SOA security architecture for a business-to-business environment.
Though the white paper focuses only on SAIC's solution, it offers a quick overview of the problem and one way to address it that should prove useful to anyone interested in SOA security.
The white paper begins by outlining why past security methods - network perimeters, passwords, user authentications and certificates - fall apart in an SOA environment:
Its loosely coupled nature severed the tight connection between user, application, and data source. Under such a scenario, designers can no longer predict every possible use case in advance.
Traditional IT environments allow you to assume a basic level of trust within your network. But with SOA, you can no longer do that.
The rest of the white paper shares how SAIC's built security into the architecture by creating a centralized Security and Identity layer, which incorporated Federated ID management, a token service and XML security appliances with domain trust and policy services.
If you already have a good grasp of the basic security challenges created by SOA, skip to InformationWeek, which this week published a lengthy piece on SOA security. The piece focuses more on the current state of the solution and the various problems associated with each solution. Currently, the article says, there are three (but two main) competing standards for authentication and authorization: 1. SAML (Security Assertion Markup Language). Microsoft doesn't support SAML. 2. WS-Federation, which the piece notes is more tightly bound to other Web services standards - and favored by Microsoft. 3. WS-Trust
And wouldn't you know it: They're incompatible.
As I said, it's a lengthy piece, with lots of charts and information, including a graph that shows you which options various SOA security vendors are - and are not - offering.
The article may be helpful, too, if your organization is still planning SOA, since it looks at the security pros and cons of using REST versus SOAP. (Hint: WS-Security doesn't work with REST. Google and Amazon solved the problem with security tokens.)
ZDNet blogger Joe McKendrick also ran a post about the InformationWeek piece, asking whether security could be the SOA show stoppper. Somehow, I doubt that. But props for the catchy headline.
McKendrick makes a good argument for viewing SOA security in the same way you would security for Web 2.0 or SaaS. All three are, in effect, opening up the enterprise IT perimeter, exposing your data, applications and, potentially, services.