WS-Security Processing Models Along with WS-SecurityPolicy
By Isuru Suriarachchi
- 22 Sep, 2008
Table of Contents
In the early days of Web services, only mechanism to validate the SOAP messages coming into a Web Services server was the “Schema based” validation model. A WSDL document is used to describe a particular Web service, and the client sends requests to the service according to that WSDL document. This classical “schema-based” validation model is used to check whether an incoming message is correct according to the WSDL document of a service.
Few years back people realized that the schema-based validation model alone is not going to provide the required level of protection for Web services. Ensuring confidentiality, Integrity and authenticity of SOAP messages exchanged between a Web services server and a client was paramount . As a result of this, WS-Security 1.0 specification was published in 2002. Later, the WS-SecurityPolicy 1.0 specification was published in the same year, in order to provide a mechanism for defining exact security requirements needed by a given service. WS-Security definitions along with WS-SecurityPolicy provides, a solid platform on which required level of security can be provided for Web services servers and messages exchanged between services and clients.
By now, there are few implementations of above the two specifications that are cable of providing a high level of security in terms of functionality. Apache Rampart is a perfect example of such a highly accepted open source implementation of WS-Security and WS-SecurityPolicy. However, currently people concentrate more on having higher level performance in addition to correct functionality. When it comes to Web services servers, level of performance of a security implementation is extremely important to protect server resources like memory and processing power. Performance of the WS-Security implementation depends on the WS-Security processing model used.
Attacks on Web Services
Attacks using messages which are not according to WSDL – Type of messages accepted by a particular Web service is defined using a WSDL document. If a SOAP message coming into a service does not adhere to the WSDL for that service, it should be rejected before delivering it to the service. This is done by the classical “schema-based” validation step.
Replay attacks – This is done by sending a large number of copies of the same message towards a service. This is avoided by using the Timestamp mechanism defined in WS-Security specification.
Violation of message Integrity and Confidentiality – WS-Security specification defines mechanisms to avoid violations of integrity and confidentiality using XML-Signature and XML-Encryption specifications.
Attacks using policy violations – As mentioned above, WS-SecurityPolicy document specifies security mechanisms required by the service. If an incoming message violates the policy, it should be rejected immediately. If not, these policy violating messages can exhaust server resources.
Out of themost common attaks on Web services mentioned, the first can be avoided by proper implementation of a “schema based” validation model. Second and third scenarios can be avoided by the correct implementation of WS-Security. But the efficiency of avoiding the fourth factor depends on your policy based WS-Security processing model. Even though the functionality defined by WS-Security and WS-SecurityPolicy is properly implemented, it doesn't guarantee the earliest rejection of policy violating messages. Clearly it's heavily dependent on the architecture of the implementation or the Processing Model. The main focus of this article is to elaborate the importance of immediately rejecting the messages which violates WS-SecurityPolicy definitions and to describe two different architectures of processing models.
Why Is It Very Important to Reject Policy Violating Messages As Early As Possible?
It is obvious that we have to reject any invalid message as soon as possible. But when it comes to policy violating messages, the earliest possible instance we get rid of it, the least it wasts unnecessary memory and processing power. That's because WS-Security processing is a very heavy task. Especially so, when a secured SOAP message contains heavy payloads that are signed and encrypted. WS-Security mechanisms are basically defined on those two heavy cryptographic operations. Because of this reason, if a message is violating the policy, it is extremely important to reject the message before the execution enters into validation steps of those cryptographic operations. In an attack like DOS attack using such invalid messages, immediate rejection can save the Web services server from resource exhaustion.
In policy based WS-Security validation, security engine has to perform two main operations:
1. Verifying elements according to WS-Security definitions.
Eg: Checking weather the timestamp is expired
Decrypting encrypted parts
2. Verifying elements against the policy definitions
Eg: Checking weather all the parts to be signed according to policy are signed in the message
Checking weather the protection order is correct
In order to perform above mentioned basic operations, the processing model must go through all the elements in the “wsse:Security” header.
Note : It is obvious that any WS-Security implementation has different processors for each and every element in “wsse:Security” header. In OOP designs these processors can be classes and in sequential designs they can be different methods. So there are processors like TimestampProcessor, SignatureProcessor, EncryptedDataProcessor etc. In following processing models, it is assumed that the design utilizes this technique.
Two Pass Processing Model
In a two pass processing model, above two steps are performed separately, independent of each other. Therefore, policy validations are done after doing all WS-Security based validations by passing the whole “wsse:Security” header. The following figure illustrated the architecture of this model.
In the first pass all the elements like timestamp, username token, signature etc. are validated according to WS-Security mechanisms. If an error occurrs, a message is discarded. Second pass can be done in two different ways. In some implementations, policy validations are done by going through the “wsse:Security” header again, whereas in some others, results are stored in a data structure within first pass and they are validated against the policy during the second pass. Both these methods can be categorized as two pass models as WS-Security processing and policy validations are done separately.
We can clearly see that the WS-Security processors shown in the figure are not policy aware. So if the message is invalid according to the policy document, it is detected only after going through all WS-Security validations. This could lead to heavy memory and processor exhaustion which is completely unnecessary.
Example scenario : Consider a message with a “Security” header which contains a Timestamp, UsernameToken, EncryptedKey and a Signature. The body is signed and also encrypted and additionally contains a heavy payload with a large amount of data. Suppose that according to the policy document, primary Signature must be encrypted. But in this message, incoming Signature is not encrypted. Therefore the message is invalid. However, a two pass processing model processes all the above tokens before validating the results with the policy. Note that signature and encryption validations are really heavy as the payload is large. However when the execution comes to the WS-SecurityPolicy validation stage, message is discarded since the Signature is not encrypted. Therefore a considerable amount of memory and processing power is wasted.
Most implementations follow this two pass model due to complexity and nature of the WS-SecurityPolicy validation process.
1. The research published as “WS-SecurityPolicy Decision and Enforcement for Web Service Firewalls” is following a two pass processing model.
2. Apache Rampart is the security module for Apache Axis2. It also uses a two pass processing model due to its dependency on WSS4J which is a separate project. WSS4J is the WS-Security implementation which is not policy aware. Only the top Rampart layer is aware of WS-SecurityPolicy. So the security validations are done in WSS4J and the result is returned back into Rampart layer. This result is validated against the policy document. Due to this restriction, Rampart also using a two pass processing model.
An improved processing model
As mentioned above, most implementations follow two pass models due to completely of policy based WS-Security processing. Although it is complex, more than 90% of the WS-SecurityPolicy validations can be done within WS-Security processors themselves. In other words, most of the policy violating messages can be identified and rejected without going through all WS-Security validating steps. Following figure shows the architecture of this improved processing model.
We can clearly see that the WS-Security processors shown in the above figure are WS-SecurityPolicy aware. Therefore, by the end of the “wsse:Security” header, most policy validations are also completed. Rest of the validations are performed after that, as shown in the figure. So the chance of rejecting policy violating messages without wasting server resources is very much higher compared to a two pass model.
In this model too, processors are called in a chain, according to the order of elements inside the “security” header. In order to perform policy validations effectively, information about tokens previously processed must be known by each and every processor. Therefore, that information must be stored in a data structure and shared among processors.
Note : In order to gain the above mentioned advantage, we must make sure that all incoming messages follow the “Strict Layout Rules” defined in section 7.7.1 of the WS-SecurityPolicy 1.1 specification. Almost all WS-Security implementations assume that messages follow these rules. So this is not a considerable restriction.
Example scenario : If we consider the same example given above, as soon as execution comes into SignatureProcessor, it can realize whether it has come through an EncryptedData processor or not. If not, the signature is not encrypted, and the message can be rejected. This helps avoid heavy signature verification of message bodies.
Importance of the XML object model
The nature of a XML parser used by the object model is extremely important when it comes to memory usage. A DOM based object model builds the entire tree of the XML document as soon as it is passed. But a StAX based object model, which uses pull parsing underneath, builds the tree only on demand of the application.
When it comes to efficient memory usage, StAX based object models are extremely important. When a message is invalid, and the memory tree is only built up to the particular point the error occured, then we can avoid wasting memory for the rest of the message.
If the object model is DOM based, there won't be any difference between above mentioned processing models, in terms of memory usage, as the entire memory tree of the incoming message is built immediately. If a StAX based object model is used with a two pass processing model, again, it can't avoid memory wasting as when the execution comes into policy processing stage (second pass), the whole tree is already built.
The most effective combination is a StAX based object model with the improved processing model. As the policy validations are performed within WS-Security processors and the memory tree is built only up to the current execution point, this combination ensures an extremely efficient processing power and memory usage.
Nowadays, people search for better performance in addition to proper functionality, when it comes to WS-Security. In other words, efficient resource utilization is essential. Although WS-SecurityPolicy validations are complex, they can be performed during WS-Security validations. That provide better performance. Usage of a StAX based object model also helps a great deal to further improve the performance gain of this proposed processing model.
Isuru Suriarachchi, Software Engineer, WSO2 Inc. [email protected]