Scenario No. 2: Application-Server-Based Fulfills Audit And Compliance Requirements
The middle of the continuum divides between two approaches, single intermediary and application-server-based, each of which is able to handle authentication and authorisation of individual users. The application-server-based approach builds on the SOA security features in service implementation platforms (e.g., application servers, integration servers, packaged applications, and software-as-a-service). By allowing service platforms to maintain security contexts based on the actual end user, this approach facilitates implementation of advanced authorisation strategies. It also allows audit logs to record actual end-user service request activity, which can be important for detailed auditing and compliance for privacy and other regulations. While it has the advantage of requiring no cash outlay for new SOA specialty products, if one has multiple platforms, the configuration and integration work required may cause the solution's cost in work hours to equal or exceed the cost of buying and configuring SOA specialty products.
Application-server-based SOA security will often use a simple VPN connection as a foundation. A possible extension of this scenario might include using an SOA or application server security plug-in from a single sign-on or identity management environment to provide for consistent security between SOA services on an application server and other application assets controlled by the identity management product.
Scenario No. 3: Single Intermediary Consolidates Security Processing
The other side of the middle of the continuum is the single intermediary approach, which concentrates SOA security functions into a policy enforcement point that sits in front of ones service implementation platforms. This simplifies SOA security, providing a single solution (consisting of the intermediary and its administrative tools) that can provide security across any and all SOA services (at least for the message formats and protocols the intermediary supports). However, in the pure implementation of this approach, service platforms, in essence, turn off user-level SOA security features in favour of trusting the intermediary for all SOA security. The intermediary might be provided by products from several different categories including SOA appliances, SOA management solutions, enterprise service buses (ESBs), integration-centric business process management suites (IC-BPMSs), or specialised SOA security products.
A single intermediary approach might also use a simple VPN connection as a foundation. The intermediary handles all SOA security processing; therefore, service platforms are not required to have any specific SOA security support, which allows the solution to support a wide range of service platforms.
Scenario No. 4: Brokered, Layered, Federated Provides Comprehensive SOA Security
At the far advanced end of the continuum, the SOA security solution is deeply integrated across multiple layers of service calls, ensuring that each service platform has access to the user's identity, and it supports advanced security scenarios such as federation and token exchange. Today, few firms even approximate this type of solution. However, as SOA security solutions, standards, and products mature and as privacy and financial regulations get more stringent, advanced SOA security solutions will become more feasible (both financially and technically) and, indeed, may be mandatory for some scenarios. A brokered, layered, federated SOA security solution will use multiple standards, integrate multiple products, and very likely require custom-built integration to pull all the pieces together.
Sign up for Computerworld eNewsletters.