|This book well justifies its addition to the prestigious ranks of Manning publications. It is well taken and timely, perhaps a little too timely, if that's possible: some of the material covered is literally so new and in such an early stage of development as to make one wonder if it has really quite gelled yet. At worst, however, the authors are over-inclusive, which is surely no crime. The reading lists at the end of each chapter are a real wonder. They alone guarantee the book will be a useful guide, even when the technical details have fallen away, as such things always do. This is the real deal about SOA security, an absolute must-read on the subject. Five stars all 'round!|
Part I - SOA basics
Chapter 1 - SOA requires new approaches to security
SOA is all about breaking down barriers between one application and another, rethinking them as services that can call upon each other as needed to increase reuse, eliminate duplication, and address common concerns in a single location. On the other hand, security is central to modern business. A lot of business information is either private to the business or private to the customer, and really shouldn't be shared with just anybody. SOA introduces new complexities into the security domain by virtue of its modularity: if service A calls service B and service C and service C requires information that shouldn't be seen by services A or B, what do we do? Review of new security approaches useful in answering questions like this one raised by SOA concludes the chapter.
Chapter 2 - Getting started with web services
This chapter addresses a number of topics required by later chapters but not really central in the main to the issue of SOA security. Installation of tools, basics of XML, SOAP, and WSDL, using Apache Axis, and a brief presentation on UDDI make up the bulk of the presentation. Although SOAP is by no means the only way to implement SOA, or even web services, the focus is on SOAP for much of the remainder of the book simply because its standard security protocols are better defined than those of other solutions.
Chapter 3 - Extending SOAP for security
It is important to implement security concerns in the right layer, and to avoid the mistakes seen in past protocols, a review of which starts this chapter. The standard solution for SOAP security is to add security information in the SOAP header, as SOAP extensions, additional entries in the header that must be understood on both the client and server side in order to be meaningful. The standard extension for SOAP security is provided by the WS-Security specification, which defines appropriate header entries and their use. JAX-RPC provides a standard API for adding SOAP extensions, and we see examples of client- and server-side processing of a simple case where the client sends directly to the server. More often, however, a message will have to pass through intermediaries, and SOAP contains rules for how intermediaries should process extensions relevant to them. Of course, if a message passes through intermediaries, there will need to be a SOAP extension to preserve the endpoint (final destination) information: this is standardized by the WS-Addressing specification.
Part II - Building blocks of SOA security
Chapter 4 - Claiming and verifying identity with passwords
User name and password - we've all seen them time and again. But how to manage user authentication with them in an SOA world? The authors provide practical advice about using clear-text and digest password authentication schemes and how to decide whether or not password authentication is right for your needs. Password authentication has significant limitations, not the least of which is the password itself, which is vulnerable to guessing or outright stealing by other users or, since we all reuse passwords, at least to some extent, for sanity's sake, malicious system administrators.
Chapter 5 - Secure authentication with Kerberos
Kerberos, a scheme used extensively in the Microsoft world, takes another approach. Passwords are still used, but are never communicated between client and server. Instead, the password is encrypted and used as the basis for a series of negotiating steps with a central authority able to authenticate the user and grant him or her permission to do what he or she needs to do. These negotiations are not simple, but the presentation here is far clearer than in many other expositions I've read. I'd recommend it even to those who are becoming interested in security in general, as a straightforward introduction to Kerberos.
Chapter 6 - Protecting confidentiality of messages using encryption
This chapter begins by reviewing the theory of encryption, discussion symmetric and asymmetric algorithms, and in particular public key infrastructure (PKI) and its associated concepts, including the basics of digital certificates, digital signatures, certificate authorities (CAs), and certificate chaining. With the aid of the XML-Encryption specification and the Apache XML Security library, a walk-through of code for the selective encryption and decryption of sensitive portions of SOAP documents makes up the bulk of the remainder.
Chapter 7 - Using digital signatures
The previous chapter covered the basics of digital signatures; this chapter focuses on specific issues of digital signatures in the context of XML (and therefore SOAP) documents. In particular, since digital signatures are quite sensitive to details of the exact sequence of bytes signed, different but equivalent forms of XML, which is fairly loose in its rules about whitespace handling, for instance, may come out with different digital signatures. Since the possibility exists that intermediates may perform some transformation that does not alter XML contents but does alter the digital signature, a set of rules for transforming XML documents is needed that can be applied to any two equivalent forms of an XML document to produce byte-for-byte equal forms. This is XML canonicalization, and, with one exception, is pretty straightforward. The exception has to do with namespace handling, where two methods are common: inclusive and exclusive. Neither is perfect. The discussion of how signature information is to be carried in a WS-Security SOAP header entry is clear and detailed. A discussion of code to sign a SOAP message and to verify the signature ensues, followed by a discussion of the importance of good choices in the use of digital signatures.
Part III - Enterprise SOA security
Chapter 8 - Implementing security as a service
In an enterprise, maintenance of many security mechanisms, each bound to a specific application and often similar to one another, can become hopelessly difficult and expensive. In software engineering, we would refactor similar code into separate methods or objects: in the same way, security can be "refactored" into a separate service of its own. Five use cases for such a service are presented and the pros and cons of each discussed. Implementation details involve surprisingly little new code, as the building blocks demonstrated in earlier chapters can be easily reused. Two new specifications are introduced, Security Assertion Markup Language (SAML) and WS-Trust. The former standardizes the format of assertions such a service might wish to make and defines an interface for invoking services producing only SAML responses; the latter defines a standard interface for invoking such security services under more general conditions. The OpenSAML library is introduced.
Chapter 9 - Codifying security policies
There are two reasons for working towards declarative-based security policies: first, it simplifies development, allowing security experts who may not be developers to contribute to the working out of security issues; second, once such policies have been worked out, it is difficult to communicate these policies from machine to machine without a common syntax. Services that might wish to work together may not be able to, owing to differences in implementation not detailed in specifications. For example, if one service requires 512-bit encryption and a potential client can only handle 128-bit encryption, that they might otherwise understand each other is irrelevant. The authors have provided a useful if disheartening table of such causes of incompatibility.
Several specifications are available that try to fill this gap: none is yet completely successful. The WS-Policy specification provides a basic approach to making policy statements and an algorithm for computing the intersection of two policies, at least approximately. We still have to get the policies to compare: that is the domain of WS-MetadataExchange and WS-PolicyAttachment. A specifically security-related extension is introduced by WS-SecurityPolicy, which standardizes assertions about matters covered by WS-Security, WS-Trust, and WS-SecureConversation. A detailed overview of how WS-SecurityPolicy assertions concludes the chapter.
Chapter 10 - Designing SOA security for a real-world enterprise
It is hard in the abstract to think about what security policies might be required in an enterprise situation. The authors present the results of obviously hard-won experience and considerable thought into what sorts of situations might occur in real-life companies and the security implications of these situations. Architectures, deployments, performance issues, and vulnerabilities are all presented in considerable detail. Of course, they can't solve every problem, but it is worth spending some time thinking about SOA and its special security issues in the context of real-world examples.
Appendices cover "Limitations of Apache Axis"; "WS-Secure Conversation", which enables the transport of a security token once, at the beginning of a conversation, after which it is used for the remainder of the conversation by all participants; "Attaching and securing binary data in SOAP"; "Securing SAML assertions"; and "Application-Oriented Networking (AON)", which converts a network into an intelligent, application- and message-aware entity that can shoulder some of the responsibility for security decisions, distributing some of that load away from applications.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)