It is often desirable to protect the confidentiality and authenticity of data conveyed in Web Service requests and responses. Confidentiality pertains to assurances that data received is exactly as sent by an authorized entity (i.e., that the received data has not been modified is some manner). Authentication pertains to assurances that the communicating entity is in fact the one that the entity claims to be. One approach for protecting the confidentiality and authenticity of data is to specify one or more sets of security policies that are applied to message that is to be conveyed over a data communications network, such as the Internet.
An example of this approach to protecting the confidentiality and authenticity of data is reflected in the standard developed by the Organization for the Advancement of Structured Information Standards (OASIS), the OASIS specification, WS-Security Policy 1.2. WS-Security Policy 1.2 describes a set of security policies that can be applied to a Simple Object Access Protocol (SOAP) message. The security policies provide a mechanism by which system and network administrators can specify generally the level and type of security required for particular Web Services provided and requested. Typically, however, more than one set of security policies can apply to a particular SOAP message because a given Web Services requester or provider has the potential to communicate with a variety of different endpoints, each with its own sets of security policies, and because there typically is more than one set of security policies that can apply to each SOAP message.
SW-Security Policy 1.2 describes three security policy “attachments” that have differing scopes that can be applied to any particular SOAP message. These security policy attachments are Endpoint Policy, Message Policy, and Operation Policy. Several combinations of security policies from the attachments can be applied to any given SOAP message. An Endpoint Policy, however, alternative must be used for each SOAP message. Each of these security policies is expressed in the Extensible Markup Language (XML), a general-purpose markup language that allows users to define their own objects and elements.
Endpoint Policy alternatives contain nested policy assertions. Though not all nested assertions are applicable to each Security Binding Assertion, some of the Endpoint Policy assertions that are of interest in the present context and that follow a nested format are: Security Binding Asertions (either Transport Binding, Symmetric Binding, Asymmetric Binding), describing whether Transport Layer Security (TLS)/Secure Sockets Layer (SSL), symmetric keys, or asymmetric key pairs will be used; AlgorithmSuite, specifying the cryptographic algorithm to use when applying encryption or producing digital signatures (there are various cryptographic algorithms that differ based upon the actual encryption and signature algorithm as well as strength of the key); IncludeTimestamp, a boolean indicator indicating whether to include a time stamp within the message to assist in protecting against replay attacks; Encryptsignature, a boolean indicator indicating whether to encrypt the main signature in the message; and ProtectTokens, indicating whether the tokens used to produce a signature are covered by a given signature.
An endpoint policy attachment (or scope), such as one specified by SW-Security Policy 1.2, typically varies to the greatest extent from location to location (e.g., from one Web Service provider to another), as it does not depend upon the content of the message body. Rather, to a considerable degree, it depends upon security decisions made by a Web Services administrator and upon the specific services requested by or provided by the particular system. An SW-Security Policy 1.2 Endpoint Policy alternative used to build a SOAP message, for example, must have a compatible Endpoint Policy alternative on the receiving endpoint. Thus, there can be multiple Endpoint Policy alternatives to choose from when building a SOAP message and when receiving a SOAP message so as to accommodate the differences.
As yet, however, there is not an effective and efficient mechanism for choosing among different endpoint policy alternatives such as those specified by SW-Security Policy 1.2. Nonetheless, efficiently choosing a particular endpoint policy alternative is important, especially in the Web Services arena since many Web Services implementations incur considerable overhead in parsing the message XML and in applying the cryptographic operations needed to protect the message. Efficiencies of any and all types are desirable so as to reduce process type and central processing unit (CPU) cycles, for example. Thus, there is a need for an effective mechanism for choosing among different Endpoint Policy alternatives.
USPTO Backgrounds
USPTO Backgrounds