- 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
Security Model Abstractions
The first refinement we can introduce to our system is to make use of an XKMS service to manage all public and private keys. This relieves us from the complexity of generating, validating, and issuing public keys of specific services to authorized requestors. (We discussed the benefits of XKMS service in detail in an earlier article in this series.)
The assumption made here is that all of the services involved in our sample scenario register their keys with a single XKMS service provider. In practice, however, there might be more than one. Moreover, it is possibile that the interactions between the PKI service provider and the services do not happen through XKMS. In this case, the underlying applications that handle Services A, B, and C have to manage the communications with the PKI authority by using other toolkits.
This refinement has certainly brought in some simplicity, but we need to go further. In the second stage, let's try to abstract the XML digital signing process.
After all, the process of generating and validating XML digital signatures will be the same, irrespective of the service. Thus, it makes sense to abstract this functionality from the business logic services. That means that the digital signature itself can be separated as an independent service, outside the realm, and can be called whenever necessary. Alternatively, instead of making it a service, - we can make use of digital signature libraries and toolkits (which the services can make use of). The methodologies can be different, but the concept of abstracting the digital signing process is important.
Going further, we can also abstract encryption and other security-related processes from the mainstream services. This argument forms the basis for Web services security models, which try to define designs and architecture that abstract security-related processes from the business logic.
)
Figure 3 Web services security abstractions.
The concept of abstraction is important because the services can then concentrate on doing what they are best at—business processes—instead of worrying about the nuances of security implementations.
One other minor development we can add with respect to the Web services scenario is this: Because SOAP has evolved as the de-facto standard protocol for all Web service interactions, it is better to build security abstractions, called SOAP extensions, on the top of SOAP message itself.
SOAP consists of a standard header and body part. The idea is to make use of the SOAP header to add additional security-related information to achieve sophisticated level of abstraction with respect to security-related data. In fact, this is one of the core concepts of WS Security (discussed in detail in the following section).