Skip to main content

Method-based security

Posted by arungupta on May 24, 2005 at 10:57 AM PDT

If a WSDL 1.1 document has two operations in a portType, how to apply different security requirements to them ?

The uninteresting cases are when there is no security applied to the message body or the message body is only signed. In both the above cases, you can peek into the message body and figure out what is the exact method being invoked on the service endpoint and thus match the security requirements.

However it becomes interesting if the incoming message in a service endpoint is encrypted because the method name is not visible in the message body. A platform may use any of the following ways to dispatch method on the service endpoint and thus can use the associated mechanisms to apply security for each method:

  1. Platform relies on SOAPAction for method dispatching. This seems incorrect behavior since WS-I Basic Profile 1.1 rules out a receiver to process the message based upon SOAPAction as per R1127. Applying security policy on the message, which includes decrypting the message and writing the body again, is "processing" the message. So relyong on SOAPAction to apply security policy to a message would be a BP 1.1 violation.
  2. The other way is to rely upon WS-Addressing Action message addressing property for message dispatching but the specification itself is not final yet.
  3. And the third approach, that we use within our XWS-Security implementation, is to decrypt the message recursively (remember the number of times decryption is performed) till an operation can be identified. Then peek into the message body to figure out the method being invoked on the service endpoint. While applying the policy, ensure that decryption (as remembered number of times) is required as part of policy, otherwise throw a policy violation error.
Related Topics >>