Sharks in the Moat

by Phil Martin

  A web service is a service exposed using web-based technologies such as the HTTP protocol along with some type of text-based payloads, such as XML or JSON. The underlying technology can be anything desired, but the various options all have benefits and disadvantages. In general, web services are best when any one of the following is true:

  Reliability and speed are not guaranteed.

  Updates to the service happen often, but the client is not easily managed.

  Various components run on different platforms.

  Products from different vendors need to interoperate.

  Existing functionality can be completely wrapped in a contract-based interface and exposed over an intranet or the Internet.

  Service Oriented Architecture (SOA)

  A service-oriented architecture, or SOA, is not a technology or a standard – it is best described as a set of principles by which we can create ultra-reusable and dependable services. SOA is usually implemented as web services accessed using either HTTP or HTTPS, but the mechanism used to access the service is not part of the SOA approach. Instead, the principles demand a certain level of reusable and agnostic measures. If you try to use Google to nail down exactly what SOA is, you will become very frustrated, as there are many definitions and descriptions subject to the respective author’s opinion. However, there are six core principles that pretty much everyone can agree on.

  SOA abstracts business functionality away from the consumer. In other words, the internal details are not exposed to the consumer. Information such as the language used, the platform the service is running on, internal business logic or database structures must remain hidden. This is a big reason that SOA services will almost always be exposed as either SOAP or REST services, since XML, JSON and HTTP are already agnostic to most of the mentioned implementation details.

  SOA exposes all functionality using a contract-based interface. Only this exposed interface is required to interact with a SOA service, and in fact should be the only mechanism for interacting with a SOA service – no fair going around it to the underlying database directly. The first principle of abstracting business functionality pretty much ensures this, but this second principle goes one step further by requiring that the interface be established as a ‘contract’ with the consumer. This means that the service promises to continue supporting an exposed interface even through future updates. Once an interface works, it should remain working even if the service undergoes extensive changes.

  A SOA service is platform neutral. Again, the abstraction principle already has us covered by ensuring that details of the platform such as OS and programming language are not exposed to the consumer. However, this third principal intimates that we could port the entire service layer onto a completely different platform if we wanted, and the consumers should never know it. As an example, we could shift SOA services from .Net to Java, and if we really held to a SOA pattern, existing clients should not have to do a single thing to remain compatible.

  SOA services are modular and reusable. Abstraction won’t help us out with this one. This principle is one of the more difficult to align with, as it requires a very careful design. This area is where most junior SOA implementors make mistakes by not following the highly cohesive and low coupling mindset. By keeping services modular and reusable, not only do we maximize their usefulness today but also for future uses we have not even thought of yet.

  Discoverability

  In my opinion, this is one of the least implemented attributes for SOA services. It is also, in my opinion, the least useful. This SOA principle states that the service should be programmatically discoverable at run-time. This is accomplished by a service environment exposing a Universal Description, Discovery and Interface, or UDDI. The UDDI theoretically allows the enterprise to discover and invoke SOA services, much like the yellow pages of a phone directory. Some might argue that a core capability of SOAP called web service descriptive language, or WSDL, is covered by this principle, as WSDL advertises the structure of the interface. It is my opinion that WSDL is an implementation of principle #2, not #5.

  Interoperability

  Abstraction helps us out one more time with this last principle, which states that internal knowledge of the structure of a service is not required to consume it, as long as the formal definition, or interface, is adhered to.

  As mentioned before, while web services are the most common method to expose SOA services, there are other methods which require the consumer to have some knowledge of the platform and binary interface, as opposed to a generic text-based interface such as XML. In my opinion, this tight coupling is sufficient to disqualify a service as SOA, but others might disagree. Some of those methods include RPC, COM, DCOM and CORBA. SOA principle #3 would appear to be completely violated by these technologies, especially DCOM and COM which are Windows-only technologies.

  From a security perspective, there are four aspects of SOA we need to be concerned with – secure messaging, resource protection, contract negotiation and trust relationships.

  SOA messages may or may not cross trust boundaries, such as between a private network and the Internet. It is always a good idea to go ahead and secure these messages even when they should never leave a private network, as an attacker that has gained entrance to the network can easily sniff messages and discover sensitive information. We have two methods at our disposal to secure SOA messages.

  First, we can use XML encryption and signatures, assuming the SOA service uses XML (it can also use JSON instead). An XML interface over HTTP is pretty much the standard for SOAP, which has a security method already built in called WS-Security. This in turn uses XML Encryption and XML Signature to assure confidentiality and integrity. Or, we can simply implement encryption on the entire communications channel, such as using TLS. When combining TLS with HTTP, we wind up with HTTPS. HTTPS will protect both SOAP and REST message payloads, whereas WS-Security is specific to SOAP only.

  Any service that needs to protect resources must implement some type of authentication and authorization. SOA is no different and should use a form of token-based authentication where a security token is provided for each and every service invocation. Alternatively, SOAP provides a built-in capability using the authentication header, and we can even use transport layer authentication.

  Publicly advertising the capability of a service allows a consumer to negotiate a contract to use. This is a core principle behind SOA and is most easily implemented when using SOAP. Web Service Descriptive Language, or WSDL, is an XML-based file that describes all inputs and outputs for a given web service. Each web service should return the WSDL when queried, and of course this necessitates protection of this interface against scanning and enumeration attacks.

  When deploying SOA services, we must be careful when allowing access to the services and ensure that the consumer is closely monitored with the correct level of access. To do this, there are four different trust relationships we can establish.

  A pairwise trust model requires that all other services a given service will interact with is available during configuration. As a new service is rolled out, all other services that can interact with it must be updated as well. As a result, this approach is not scalable.

  A brokered trust model can overcome this limitation by using a third party that acts as a broker to provide identity information. With this model, we can roll out new services without having to reconfigure existing services, as all only know about the third-party broker.

  A federated trust model is used when two organizations wish to have their respective services talk to each other. Due to security issues, this requires the various contracts, protocols and interfaces to be well-known beforehand. However, either the pairwise or brokered trust models can be used for actual service-to-service interactions.

  A proxy trust model uses perimeter network devices to proxy incoming calls and to handle security on the service’s behalf. While this does allow configuration at a single point, it introduces a single
point of failure unless a layered defense is implemented with least privilege controls.

  SOAP and REST

  When exposing SOA services, most often we will use some type of HTTP-based mechanism such as SOAP or REST.

  Although we have touched on SOAP several times before, let’s officially define it. The simple object access protocol is a messaging protocol for exchanging information using web services. It uses XML for its message format and almost always is built on top of HTTP, although other protocols have been used as well. SOAP is relatively heavy, meaning the payloads are large, but it is extensible and provides robust security.

  On the other hand, representational state transfer, or REST, is also an HTTP-based standard that can be XML or JSON (javascript object notation) based. While it natively provides no security, it is much lighter, meaning that it performs well relative to SOAP. REST is becoming more and more ubiquitous and is quickly replacing SOAP as the public preference. However, when security is paramount, such as that used within a bank’s intranet, you will still often find SOAP in-use.

  Whereas SOAP is focused on providing singular methods, REST operates on the concept of name-something-and-take-action. For example, if I have a system that tracks sports equipment at a gym that can be rented, I would probably have the following SOAP methods:

  RetrieveSoccerBallInfo()

  RentSoccerBall()

  ReturnSoccerBall()

  REST would instead theoretically define ‘SoccerBall’ as something to be acted on:

  SoccerBall.Retrieve()

  SoccerBall.Rent()

  SoccerBall.Return()

  Of course, that’s not really how REST implements web services. REST assumes a finite number of ‘verbs’ that will act on ‘things’. The most common verbs are:

  Get – retrieve something.

  Put – create something.

  Post – update something.

  Delete – delete something.

  So, REST would actually look like this in our example:

  URL

  HTTP Verb

  /soccerball

  GET

  /soccerball/rental

  PUT

  /soccerball/rental

  DELETE

  In summary, both SOAP and REST have their pros and cons, SOAP is heavier, slower, and more complex than REST, but it is very extensible and secure. REST is lighter, faster and simpler than SOAP, but is has no security whatsoever and cannot be easily extended. Transport layer security such as TLS is most often used to provide encryption for REST, but authentication is still way outside the scope of this protocol. Having made the comment about REST’s lack of extensibility, though, be aware that implementing named resources with REST is somewhat of an art, and if done properly can provide as much functionality as you would ever need.

  Enterprise Services Bus (ESB)

  While SOA provides a robust way to implement services, at some point those services will need to interact with some backend process. An enterprise service bus, or ESB, is a software architectural pattern that allows asynchronous communication between two layers within a system, or even between two systems. There are two primary security advantages to implementing an ESB – it allows security to be implemented in a single place and it allows the ESB to act as the reference monitor, or ‘traffic cop’. These two attributes support the principle of complete mediation. For example, we might implement the following mediation modules:

  An authentication module that uses a common directory service.

  An authorization module using external access management services.

  A logging module used to log all messages coming into and leaving the ESB.

  An availability module that monitors capacity and network flow.

  A validation module that can filter messages coming into or leaving the ESB.

  A cryptographic module offering encryption, decryption and hashing services.

  On the downside, an ESB can represent a single point of failure, so it must be designed with redundancy in mind. An ESB might also introduce a weakness by directly connecting a secure zone and the DMZ. In such cases, it might be wise to implement both an internal and an external ESB that are bridged together in a secure fashion. Figure 110 illustrates how an ESB might be used across disparate platforms.

  Figure 110: Enterprise Service Bus

  Encryption

  When covering the Development role, we discussed encryption quite a bit. However, there are a few nuances around cryptographic capabilities that are more applicable to the Architect role.

  Certificate and Registration Authorities

  We’ve been talking around CAs for a while, so let’s dig in and see what all the fuss is about at the risk of repeating some material. A certification authority is a trusted third-party who manages public keys and certificates. Anyone who wants to generate a public/private key pair must work with a CA, and there are many in the world all working together. CAs also maintain a list of revoked certifications that are no longer valid called the certificate revocation list, or CRL. Certificates may be voluntarily revoked by their owner, but more often the case is that a private key has been disclosed, rendering the certificate untrustworthy.

  Each certificate contains a certificate practice statement, or CPS, that describes how the CA issues certificates. It may contain some or all of the following elements:

  The type of certificates issued.

  Policies, procedures and processes for issuing, renewing and recovering certificates.

  Cryptographic algorithms used.

  The key length used for the certificate.

  The lifetime of the certificate issued by the CA.

  Policies for revoking certificates.

  Policies for CRLs.

  Policies for renewing certificates.

  A CA may delegate certain functions to a registration authority, or RA. What RAs actually do will vary depending on the need of the delegating CA, but generally include most of the following functions:

  Verifying information supplied by the subject.

  Verifying the right of the subject to requested certificate attributes.

  Verifying that the subject actually possesses the private key being registered and that it matches the public key requested for a certificate.

  Reporting key compromise or termination cases where revocation is required.

  Assigning names for identification purposes.

  Generating shared secrets for use during the initialization and certificate pick-up phases of registration.

  Initiating the registration process with the CA on behalf of the subject entity.

  Initiating the key recovery process.

  Distributing physical tokens, such as smart cards, containing private keys.

  X.509

  A digital certificate is used to associate a public key with data sufficient to verify an owner’s identity. The standard for this is called X.509, with X.509v3 being the most commonly used version. This standard dictates the various fields that are contained within the certificate and is used by SSL, TLS and other cryptographic protocols. At a minimum, a certificate contains the following attributes:

  Version (of the certificate)

  Serial number

  Signature (algorithm used to sign)

  Issuer (CA who issued the certificate)

  Issuer unique ID (ID of issuing CA)

  Subject (name of owner)

  Subject unique ID

  Validity (dates)

  Public key

  Extensions (optional extensions)

  Key Scalability

  Let’s take a slight detour and discuss key scalability for a moment, dealing with a core issue in symmetric algorithms. Symmetric keys are also called secret keys, because they must be kept secret for the algorithm to work securely. Both the sender and receiver must possess the same key, which is not a big deal between two people – we only have to manage two instances of the key. But when the sender wants to send encrypted data to 5 recipients, this would r
equire the management of 6 instances of the key – one copy for the sender and five copies for the recipients.

  Now imagine 10 people wanting to send data back and forth between each other. Each unique pair would need a key. The equation to calculate the number of keys needed for a symmetric algorithm is:

  Number of keys = n(n-1)/2 where n is the number of individuals involved

  So, 10 people all communicating with each other would result in 45 different keys. This is complicated when you think of how you are going to get all those keys sent securely to each recipient. And then think of the overhead involved when you want to change the keys. Obviously, key management is the Achilles heel of symmetric algorithms. Asymmetric algorithms do not have this problem, as a single private/public pair can work for any number of recipients. Additionally, symmetric algorithms provide confidentiality, but not integrity and nonrepudiation as asymmetric cryptography does.

  If that is the case, then why use symmetric algorithms at all? Because they are extremely fast compared to asymmetric algorithms, and harder to break when used with a large key size, or a large keyspace. Here is a list of symmetric algorithms:

  Data encryption standard (DES)

  Triple-DES (3DES)

  Blowfish

  International data encryption algorithm (IDEA)

  RC4, RC5, and RC6

  Advanced encryption standard (AES)

  In summary, symmetric cryptography excels at encrypting large amounts of data and is harder to break but provides confidentiality only.

  Applying Encryption in the Real World