Chapter 4. Security and manageability patterns
In this chapter
As I mentioned in chapter 1, SOA promotes loose coupling by emphasizing interfaces, standards-based contracts, and service autonomy. SOA’s loose coupling of services makes it (relatively) easy to create systems by composing services together, and it lets you update services without disrupting other services that interact with the changed service. SOA is truly an open architecture style. This openness offers a lot of benefits, like agility and easier integration, but it also opens the door to many security threats and manageability challenges. In the past, there was always a tradeoff when choosing between openness and security or distribution and manageability, so you might think it would be difficult to weave security and manageability into SOA without violating SOA’s principles. As you’ll see in this chapter, a good balance between these somewhat contradictory quality attributes can be achieved.
Before we dive into the solutions, let’s look at some of the problems they try to solve. Software systems, especially distributed and connected systems, have to deal with many threats. One example is repudiation—someone denying that they sent a message. Another example is distributed denial of service attacks, which are quite common these days.
When building SOAs, you’re more likely than not using XML for your messages (although other options like JSON or proprietary formats are also possible). If you are using XML, two technological standards you should be aware of are XML encryption and XML signatures—both are W3C standards and both are supported by many development environments. For instance, Apache Santuario, the Apache XML security project, has implementations for Java and C++. .NET 4 has a specific namespace that deals with XML cryptography(System.Security.Cryptography.Xml).
In regard to general quality attributes, you can see that the Secured Message pattern is a little problematic. One problem is that it requires a lot of work on the service implementation, which means it has an impact on maintainability. Also, because it’s your responsibility to implement this pattern, you need to be careful and comply with standards; otherwise, it can have a bad effect on interoperability.
One option is to develop the security solution yourself. To minimize the effect on the services, you can put most of the security-related code in an edge component (see the Edge Component pattern in chapter 2). But you still have to develop the security solution, and even more importantly, test it. Also, you’d need to make sure you use security standards to enable interoperability with external parties—don’t forget that openness is an important trait for an SOA.
What’s important here is that ESBs offer secured communications and they provide a means to expose services using the previously discussed technologies. You can also use ESBs to route messages, which makes it easy to introduce additional security mechanisms, such as implementations of the Service Firewall or Service Monitor patterns (both discussed later in this chapter). Essentially if you expose all your services over an ESB, you can use it as a central point to perform the three As—authentication, authorization, and auditing.
Another implementation option for the Service Firewall pattern is using hardware or embedded appliances. Companies like Layer 7, IBM (DataPower appliances), Vordel, and a few others produce XML firewall appliances. The advantage of using XML appliances is that you can deploy them along with your other firewalls in the DMZ and have them serve as the first line of defense. Another advantage is that these platforms are optimized for XML handling, so the performance impact of the appliances is lower than a self-coded solution. One disadvantage of using hardware XML firewalls is the setup costs (tens of thousands per unit); another is the increased maintenance complexity of managing an additional hardware type and performing the double management of your SOA contract (both in the service and in the appliance).
In addition to the specifics of the threats that the Service Firewall pattern helps mitigate, you can also look at it from the wider scope of quality attributes. Like most of the other patterns in this chapter, Service Firewall is a security pattern. It’s interesting to note that unlike most other security patterns, it’s relatively easy to add it on toward the end of a project, although this is not a completely free ride. You still have to measure its impact on system performance—it can add an overhead in regards to contract maintenance and the like.
How does the identity provider work? The core concept is trust, and the mechanics for using it build on previously successful infrastructures like PKI. A service consumer, which has gone through provisioning with an identity provider at some time in the past, tries to access a service. When sending a message, the service consumer makes some assertions about its identity, its capabilities, or both. If the service trusts the identity provider, it can ask the identity provider if the claims made by the service consumer are genuine, and if they are it can accept the service consumer’s request.
If we return to the journal subscription agency scenario presented in the problem description, the authentication and authorization can follow the steps in figure 4.12. The Proposals service gets ready to send a request to the Customer service to get a list of discounts for a customer. It will then digitally sign this request as a proof that it has credentials in the identity provider. The Customer service can then check this claim with the identity provider, which will return a token or a certificate that verifies that the Proposals service is entitled for this service. The identity provider signs this certificate with its private key. The Customer service can then verify that the identity provider signed the certificate, and because it trusts the identity provider, it can honor the certificate and return the list of discounts to the Proposals service.
Figure 4.14 shows services that are likely to be found in a typical e-commerce system. The system has an Ordering service that handles the shopping cart until an order is finalized. It then interacts with an Invoicing service, which processes credit cards and other payment methods. The Ordering service also interacts with the Warehouse service to secure items or order them from suppliers and a Shipping service that monitors the activity until a package is ready. The Shipping service also interacts with the Warehouse service and with a Tracking service that verifies an order is fulfilled against multiple shipping companies.
One thing you can do is increase the reliability and availability of each service. This can be done by applying patterns like Service Instance or Virtual Endpoint (both discussed in chapter 3). Using these patterns will help make each service more available, but there’s still a chance that something will go wrong, and then what? An even more important problem is that a service is rarely truly isolated. Services usually need to interact with other services, so the reliability of each service is also affected by the reliability of the services it has to interact with.
This chapter took us through several patterns needed to secure SOA implementations. Two of the patterns also management and maintainability aspects even though they also relate to security.
While these patterns are, in my opinion, very useful and valuable for securing and making your SOA more maintainable, you should keep in mind that making an SOA solution (or any solution) secure and maintainable goes well beyond these patterns. The patterns listed here deal mainly with the interfaces of your SOA; you still need to make sure the business logic you write is both secure and maintainable, especially if the service is distributed internally. For instance, when you log errors or messages or persist data in the database, you should pay attention not to log sensitive information.
Bilal Siddiqui, “Exploring XML Encryption, Part 1: Demonstrating the secure exchange of structured data,” IBM developerWorks, www-128.ibm.com/developerworks/xml/library/x-encrypt/. This article is a primer on XML encryption, which is one way to implement the Secured Message pattern.
OAuth 2.0, http://oauth.net/2/. OAuth is an authentication standard commonly used in REST-based systems and REST-based SOA implementations.