Web Service Security Architectures, Part I
- Web Services Security Models
- Security Model Abstractions
- WS Security
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In a sense, the articles in this series have discussed XML security, rather than Web services security. The topics included SAML, XML encryption, XML digital signatures and XKMS. All of them discussed XML security aspects in detail, not Web services security in particular.
Partly, this is because Web services security architecture as a whole is built around these small bits and pieces. XML is the foundation of Web services, and we can leverage whatever technologies we have built for securing XML to also secure Web services.
Moreover, Web services technology itself is in its very early stages, and neutral bodies and consortia are working hard to evolve common Web services security specifications that are acceptable to all vendors and platforms. Thus, standardization has just begun with XML security specifications, and down the line it will be extended to Web services as well.
This article discusses some of the common aspects of a comprehensive Web services security architecture—the problems and challenges it poses. Next, there is a discussion of WS Security, a major Web services security model initiative pioneered by IBM and Microsoft.
Web Services Security Models
When thinking about a comprehensive security model for Web services, the first thing that strikes us is that it is not point-to-point security for which we have so many solutions in place. All security models that have evolved so far have been based on a client/server model, which is essentially point-to-point security.
For example, a sender of a confidential message encrypts and signs the message using the receiver's public key, and transmits it across the wire. The receiver decrypts the message using his public key. This model works well if only two parties are involved in the communication; if a third party is introduced in the middle, the model collapses.
In Web services, we see several services interacting with each other in a random manner. For example, a feed rate service may have the option to select either service A or B at random, based upon certain criteria such as availability, quality of service, cost, and so on. Now, how are we to provide security to such a transaction, which doesn't even follow the same structure for each transaction? The confusion only compounds further if we think about dynamic Web services, in which the feed rate service may not even know beforehand whether its choice is limited to service A and B.
As we think further about this security model for Web services, we will find that the challenges we have to address are related to business (how to dynamically establish partnerships, evolve trusted service federations, and so on) as well as technology (message security, encryption/decryption, public keys exchange, etc.).
Ideally, the participating Web services in a transaction should not bother much about security aspects in the communication, and the underlying security infrastructure should transparently provide a basic security layer for the confidential XML data exchanged—such as data integrity, confidentiality, and non-repudiation.
Let's consider two simple Web services interaction scenarios, and discuss the security issues that come to play and how we can address them.
In scenario 1 (see Figure 1), Service A transmits some XML information to Service B, which in turn adds some more data and passes it on to Service C (the end consumer). The entire communication must be secure and confidential.
)
Figure 1 Web services interaction: scenario 1.
Let's assume that all three services are processed by three different systems, and there is no level of trust or relationship between them.
Now, how can we secure this communication?
One option is this: Service A can encrypt the data it is sending by using Service C's public key. It can also sign the document by using XML digital signatures in order to take responsibility for what it is sending. Service B just adds some more information to the data stream so it can also make use of Service C's public key to encrypt the data and sign it, if need be.
Service C, upon receiving the document, can decrypt the data by using its private key. It can also ensure that the document has not been tampered with while in transit by using the XML signatures.
Sounds very simple, eh?
Remember that Service A's transmission was encrypted and signed. Service B can encrypt and sign the document further (encryption over already encrypted data), or it can append its own encrypted portions to the document. Service C needs to be aware of this methodology, so that it can decrypt the document accordingly. Also, the verification of signatures at Service C implies that Services A and B have public and private keys that need to be appropriately transmitted to Service C. Apart from the complexity of maintaining and transmitting public and private keys at each service, the overhead of encryption/decryption and digital signature verification cycles is very substantial. Repeating this cycle over and over again for each and every transaction will only have a negative effect on the overall performance of the system.
Moreover, we have not discussed how Service A initially decided to work with Service B in order to deliver a secure document to Service C. Nor did we bother about how Service C entirely trusts the data coming from A and B.
From a business perspective, it is difficult to achieve such levels of trust across different functionally independent systems and domains.
As we delve deeper, we will hit many more issues, but this is just to illustrate that building security around what seems to be a simple Web service transaction is costly and sometimes complex.
Now, let's slightly modify this scenario to illustrate the loosely coupled model of Web services interactions (see Figure 2).
Let's say that Service A has the option of selecting Service B or D at random—based upon certain criteria—before the data is passed on to Service C for final consumption. Such run time decision-making capabilities make Web services much more attractive. For example, Service A can see whether Service B is available or not; if it is not available because of some reason, it can contact Service D, which in this case serves as a substitute for B.
Another example could be that Service B's commissions are attractive in some cases, whereas Service D is cost-effective in certain other cases.
)
Figure 2 Web services interaction: scenario 2.
This simple change dramatically introduces several complexities into the security model.
Apart from the complexity of handling one more public and private key, Service C has to be made aware of whether Service B or D serviced this particular transaction, so the signature can be verified accordingly. As we keep adding more and more services, we end up with multitudes of key pairs and encryption/decryption/signing processes for a single transaction service. Moreover, we are already far from our ultimate goal of providing transparent security infrastructure to all participating services.
Thus, we have to radically rethink the way we have been defining our security architecture.