The Service view contains several assumptions about the client that is connecting to it and the data it is being sent. First, is that the client and the data are not to be trusted per se, but they can undergo a verification process. In an SOA world the client and the server live in different environments and trust zones; and may be written in different languages altogether. The service exists to facilitate the communication process among these disparate entities and to join the identity with its required data.
The elements that concern security in the Service View are similar to those threats and vulnerabilities that exist in a web application. The concerns center around validation of data, access control, exception handling and management, and server configuration. Again similar to web and other distributed applications, the application architect and security architects must decide once the call process leaves the service space whether to execute the call as an impersonation or delegation.
In the Service View, we also want to consider the client side of the service. The client needs to know that the information it receives back is backed by some guarantee of integrity, that the host it connects to is the right one, and that there is some assurance it will be available.
The Service itself may require authentication, authorization, and other security-centric attribute assertions be made through some type of federated identity mechanism. The Service may require that the XML payload contains role information so that the service can execute against that, make security decisions, and propagate those credentials to its own dependent applications.
Each of the SOS views has its own set of concerns, threat, vulnerabilties, and solution patterns. Patterns that emerge in the Service View include the Security Pipeline Interface pattern. The Security Pipeline Interface is repsonsible for securing information flow between hosts in different security domains. The Security Pipeline Interface infers no trust in the calls it receives, but requires that the caller provide evidence that it is to be trusted. In the implementation, the recipient process is partitioned off from the following processes in the pipeline. The Pipeline applies rules and filters information before it is sent along the call chain.
Comments