Patent Application
20090077615
1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, apparatus, and products for security policy validation for web services.
2. Description of Related Art
Many enterprises are currently undertaking development using the Service-Oriented Architecture (‘SOA’) because their business models are changing more frequently. SOA makes application development easier because technology-independent services can be coupled over intranets and via the Internet. As business models are changing more frequently, the underlying computing environments on which the applications are running are becoming more complex because computers can be networked using complicated topologies, including firewalls and intermediate servers. Consequently, the proper configuration of non-functional aspects such as security requires a fairly deep understanding of such complex environments.
In light of such developments, unifying security with the software engineering process from the beginning is important. Unfortunately, security is often considered as an afterthought in most actual developments in the sense that security is added after the functional requirements are implemented. It is well known, however, that correcting defects in the late stages of the design process greatly increases the costs of removal and repair of those defects.
More recently, the Service Component Architecture (‘SCA’) is being standardized as a component model for SOA. Intentions for non-functional requirements such as security and transactions are specified at an abstract level in SCA's Policy Framework, and these intentions are being mapped into concrete policies such as WS-SecurityPolicy. According to the SCA Policy Framework, software engineers should prepare in advance a collection of WS-SecurityPolicy documents so that policies are retrieved from the security intentions attached to the SCA components. Therefore, it is important to define valid policy documents for the SCA components from the beginning of the development process.
To guide the development of security policies, most enterprises have security guidelines in the form of security profiles that describe the format of Web services security messages. In addition, there also exist standard profiles on Web services security such as, for example, WS-I Basic Security Profile that also prescribes industry standard security message formats. In the current art, however, the process of determining whether a security policy comports with a security profile is a manual process fraught with error due to the complexity of SOA environments. As such, readers will appreciate room for improvement exists in security policy validation for web services.
Methods, apparatus, and products are disclosed for security policy validation for web services that include: transforming a security policy for a web service into a policy predicate logic representation; providing a profile predicate logic representation that represents one or more rules of a security policy profile; determining whether the security policy satisfies the security policy profile in dependence upon the policy predicate logic representation and the profile predicate logic representation; and notifying a user that the security policy is valid if the security policy satisfies the security policy profile.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.
Exemplary methods, apparatus, and products for security policy validation for web services in accordance with the present invention are described with reference to the accompanying drawings, beginning with
In the exemplary system of
A web service message implemented using SOAP is an ordinary XML document that contains the following elements:
To secure the exchange of SOAP messages, web services typically utilize security tokens and other security mechanisms to protect the web service messages. One format for embedding security tokens and using other security features to protect web service messages is described in the WS-Security specification promulgated by the Organization for the Advancement of Structured Information Standards (‘OASIS’). The WS-Security specification describes how to attach digital signature and encryption headers to SOAP messages. In addition, WS-Security describes how to attach security tokens, including binary security tokens such as, for example, X.509 certificates and Kerberos tickets, to web service messages. Readers will note that a web service message that implements security protections is referred to as a ‘web service security message.’
In a web service security message, application data is embedded in the Body element, while security information is embedded in the Header element. For example, consider the following web service security message:
The exemplary web services security message above illustrates application data contained within the Body element specified by the XML tags <soap:Body> and </soap:Body> and security data contained within the Header element specified by the XML tags <soap:Header> and </soap:Header>. The Header element above includes a X.509 security token in the BinarySecurityToken element specified by the XML tags <wsse:BinarySecurityToken> and </wsse:BinarySecurityToken>. The Header element above also includes a digital signature in the Signature element specified by the XML tags <ds:Signature> and </ds:Signature>. The Signature element specifies the following information:
To create and identify web service messages that have particular security features, a web service utilizes a security policy such as the web service security policy (106) stored in RAM (168) of the computing device (152) in
A binding also specifies encryption algorithms, security token information, and a layout for the elements in a web service message. Supporting tokens are additional tokens that are not described in a binding section.
Consider, for example, the following web service security policy used for verifying or generating the exemplary web service security message described above:
The exemplary web service security policy above illustrates an integrity assertion using a ‘SignedParts’ element denoted by the XML tags <sp:SignedParts> and </sp:SignedParts>. The ‘SignedParts’ element requires that the Body element of a web service security message be signed. The exemplary web service security policy above also illustrates a binding section using an ‘AsymmetricBinding’ section denoted by the XML tags <sp:AsymmetricBinding> and </sp:AsymmetricBinding>. The ‘AsymmetricBinding’ section specifies that the Header element of a web service security message must include a X.509 certificate, that the ‘Basic256’ algorithm suite is used to sign and encrypt a security message, and that a ‘strict’ layout is used for arranging the elements in the security message. Readers will note that the exemplary web service security policy above omits logical operators such as, for example, ‘all’ or ‘ExactlyOne,’ for clarity. Logical operators useful in web service security policies may include those specified in WS-SecurityPolicy.
Because a security policy may be utilized in a variety of different runtime environments, the computing device (152) includes runtime configuration (107) stored in RAM (168). The runtime configuration (107) of
In the example of
Also stored in RAM (168) of
In addition to determining whether a security policy is valid with respect to the rules of a security profile, the policy validation module (102) may also determine whether a security policy is valid with respect to the runtime configuration for the runtime environment in which the policy is utilized. Such validation ensures that a security policy that calls for a X.509 key is deployed in an environment that in fact has an X.509 key. As such, the policy validation module (102) may also operate generally for security policy validation for web services according to embodiments of the present invention by: providing a runtime configuration predicate logic representation (105) that represents one or more configuration parameters of a runtime configuration environment (107); and determining whether the security policy (106) matches the runtime configuration environment (107) in dependence upon the policy predicate logic representation (101) and the runtime configuration predicate logic representation (105).
Also stored in RAM (168) is an operating system (154). Operating systems useful for applying firmware updates to servers in a data center according to embodiments of the present invention include UNIX™, Linux™, Microsoft XP™, AIX™, IBM's i5/OS™, and others as will occur to those of skill in the art. The operating system (154), the web service (108), web service security policy (106), the security policy profile (103), the policy predicate logic representation (101), the profile predicate logic representation (104), the runtime configuration (107), the runtime configuration predication logic representation (105), and the policy validation module (102) in the example of
The computing device (152) of
The example computing device (152) of
The exemplary computing device (152) of
The arrangement of servers and other devices making up the exemplary system illustrated in
For further explanation,
In the example of
As mentioned above, software architects use the guidelines of an organization's own proprietary security profile or an industry standard security profile such as WS-I BSP to develop a security policy used by a web service. As illustrated in
As mentioned above, the security profiles (200, 202) and the security policies (204, 206, 208) are represented as predicate logic representations (210) in the example of
Facts and rules in Prolog are typically arranged in predicate logic form. For example, the following is an exemplary set of three Prolog clauses:
Prolog clauses are normally of three types: Facts declare things that are true. Rules declare things that are true depending on a given condition. Questions are used to find out if a particular rule is presently satisfied by asserted facts, when the rule is said to be ‘true.’ Prolog questions are sometimes referred to as ‘goals’ or ‘queries.’ In the three-line example above, “parent(fred, greta) is a fact. “Parent” is a predicate. “Fred” is the first argument, sometimes called a ‘subject.’ “Greta” is the second argument, sometimes called an ‘object.’
In the three-line example above, “grandparent(X, Z):-parent(X, Y), parent(Y, Z).” is a rule. “Grandparent(X, Z)” is referred to as the ‘head’ of the rule. “Parent(X, Y), parent(Y, Z)” is referred to as the ‘body’ of the rule. “Parent(X, Y)” is the first subgoal of the rule. “Parent(Y, Z)” is the second subgoal of the rule. X, Y, and Z are variables.
This example rule is correctly described in several ways. One declarative description is: For all X and Z, X is a grandparent of Z if there exists some Y such that X is a parent of Y and Y is a parent of Z. Another declarative description is: For all X, Y and Z, if X is a parent of Y and Y is a parent of Z then X is a grandparent of Z. A procedural interpretation of the rule is: The goal grandparent(X, Z) succeeds with binding X1 for X and binding Z1 for Z if first, the goal parent(X, Y) succeeds with bindings X1 and Y1 and then the goal parent(Y, Z) succeeds with bindings Y1 and Z1.
A Prolog goal is said to ‘succeed’ if it can be satisfied from a set of clauses in a Prolog database. A goal fails if it cannot be so satisfied. For an example based upon the three-line set of example Prolog clauses set forth above: the query “grandparent(fred, X).” is satisfied with X instantiated to henry. On the other hand, the query “grandparent(fred, bob).” is not capable of being satisfied from the three-line exemplary Prolog database, because ‘bob’ does not appear in that set of clauses.
For further explanation,
The Prolog rule illustrated above in lines 01-23 is used to implement the policy predicate logic representation for the exemplary security policy described above with reference to
Transforming (300) a security policy (106) for a web service into a policy predicate logic representation (101) according to the method of
into the following fragment of a policy predicate logic representation:
and into the following addition fragment of a policy predicate logic representation:
body(@id(BodyID))
In the example above, because the ‘SignedParts’ element in the security policy fragment requires a signature element in the message, the ‘sig’ policy predicate logic representation fragment above also specifies that a message requires a signature element. Moreover, because the ‘SignedParts’ element in the security policy fragment specifies that the Body of the message is signed, the ‘body’ policy predicate logic representation fragment above specifies that a message requires a Body element. For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
into the following fragment of a policy predicate logic representation:
and into the following addition fragment of a policy predicate logic representation:
In the example above, because the ‘EncryptedParts’ element in the security policy fragment requires that the Body element of a message be encrypted, the ‘encKey’ and the ‘encData’ policy predicate logic representation fragments above specify encryption key information and encryption data information that is required in a web service message.
For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
into the following fragment of a policy predicate logic representation:
In the example above, a primitive rule is used to transform the security policy fragment that requires an X.509 security token for the signed portion of the message into a ‘bst’ policy predicate logic representation fragment that specifies a message should have an X.509 binary signature token (‘bst’).
For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
into the following fragment of a policy predicate logic representation:
In the example above, a primitive rule is used to transform the security policy fragment that requires a username security token for the signed portion of the message into a ‘usernametoken’ policy predicate logic representation fragment that specifies a message should have a username/password combination.
For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
<sp:MustSupportRefKeyIdentifier/>
into the following fragment of a policy predicate logic representation:
keyID(EncordingType(***), @ValueType(***), keyIdentifier).
In the example above, a primitive rule is used to transform the security policy fragment that requires a web service message to support a reference token identifier into a ‘keyID’ policy predicate logic representation fragment that specifies a message should specify a reference key identifier.
For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
<sp:MustSupportRefIssuerSerial/>
into the following fragment of a policy predicate logic representation:
In the example above, a primitive rule is used to transform the security policy fragment that requires a web service message to support a reference to a token issuer into a ‘STR’ policy predicate logic representation fragment that specifies a message should specify an X.509 issuer.
For further example, a primitive rule may provide the instructions for transforming the following security policy fragment:
<sp:MustSupportRefEmbeddedToken/>
into the following fragment of a policy predicate logic representation:
STR(Embedded(@id(***), ***)).
In the example above, a primitive rule is used to transform the security policy fragment that requires a web service message to support a reference to an embedded token into a ‘STR’ policy predicate logic representation fragment that specifies a message should specify an identifier for an embedded security token. Readers will note that the policy predicate logic representation fragments above generated by primitive rules from the security policy fragments are fragments of a Prolog rule. The Prolog rule fragments above are illustrated for explanation and not for limitation. Primitive rules may be used to transform a security policy fragments into other forms of policy predicate logic representation fragments as will occur to those of skill in the art.
Structure rules are transformation rules that express the message element structure requirements of the security policy (106) into the policy predicate logic representation (101). For example, a ‘Layout’ element in a security policy defines the order of elements in a SOAP message header, and an ‘EncryptBeforeSigning’ element in a security policy requires that encryption must be performed before signing.
Merging rules are transformation rules that define how to merge the policy predicate logic representation fragments created by primitive rules into a single policy predicate logic representation. Using only primitive rules and structure rules, the constructed policy predicate logic representation may have redundant elements or may lack necessary associations between elements. Consider, for example, the following portion of a web service security policy:
and the following portion of its corresponding policy predicate logic representation:
Using primitive rules, the ‘X509Token’ element and the ‘SignedParts’ element are transformed into the ‘bst’ element and the ‘sig’ element, respectively. In applying a merger rule, readers will note that the ‘Basic256’ identifier under the ‘AlgorithmSuite’ element in the security policy is used to specify an algorithm for the signature. As such, a merger rule in the example above associates the X.509 token with the ‘sig’ element, applying the rule that the signature element created by ‘SignedParts’ element must refer to a token specified in the ‘InitiatorToken’ element.
The method of
A software architect may provide the following profile predicate logic representation of the exemplary security profile rule above:
The exemplary security profile rule above in lines 01-08 is implemented as a Prolog rule. ‘c5443(E)’ in line 01 serves as the head of the Prolog rule and everything in lines 02-08 serve as the body of the Prolog rule. The Prolog rule illustrated above specifies that all web service messages that conform to the goals in the body of the Prolog rule, namely that the signature includes signature reference that refers to the signer's security token, also conform to the security profile rule ‘c5443.’ That is, if each of the goals in lines 02-08 of the Prolog rule above is true for a particular web service message, then it is true that the web service message conforms to the security profile rule ‘c5443.’
The method of
myPolicy(E),˜c5443(E)
The exemplary Prolog expression above evaluates to true if a web service message ‘E’ exists that does not satisfy the ‘c5443’ security profile rule but does satisfy the ‘myPolicy’ security policy. The exemplary Prolog expression above evaluates to false if no web service message ‘E’ exists that does not satisfy the ‘c5443’ security profile rule but does satisfy the ‘myPolicy’ security policy. If the expression ‘myPolicy(E),˜c5443(E)’ evaluates to false, therefore, then the security policy (106) satisfies the security policy profile (103). The security policy (106) does not satisfy the security policy profile (103), however, if the expression ‘myPolicy(E),˜c5443(E)’ evaluates to true. As discussed in more detail below, when the security policy (106) does not satisfy the security policy profile (103), Prolog may provide an example of a web service message satisfying the expression ‘myPolicy(E),˜c5443(E),’ thereby providing a policy developer with an example message demonstrating that the security policy (106) does not satisfy the security policy profile (103). The policy developer may utilize such an exemplary message to identify why the security policy (106) does not satisfy the security policy profile (103). From the discussion above, readers will note that after the security policy (106) and the security profile (103) are represented in predicate logic representations, then determining (306) whether the security policy (106) satisfies the security policy profile (103) may be carried out merely by evaluating a predicate logic expression using the representations.
The method of
The method of
myPolicy(E),˜c5443(E)
If the Prolog expression above evaluates to true, then Prolog returns an instance of a web service message ‘E’ that satisfies the expression. That is, Prolog returns an example message that does not satisfy the ‘c5443’ security profile rule but does satisfy the ‘myPolicy’ security policy. Such an example of a message demonstrating that the security policy (106) does not satisfy the security policy profile (103) may be useful to a software architect in modifying the security policy (106) to comport with the security policy (103).
The explanation above with reference to
The method of
The exemplary runtime configuration predicate logic representation above in lines 01-05 is implemented as a Prolog rule. ‘RTEnvironment(E)’ in line 01 serves as the head of the Prolog rule and everything in lines 02-05 serve as the body of the Prolog rule. The Prolog rule illustrated above describes all web service messages ‘E’ that are supported by a particular runtime configuration environment. That is, the rule ‘RTEnvironment(E)’ is true for all messages that are supported by the particular runtime configuration environment, and the rule ‘RTEnvironment(E)’ is false for all messages that are not supported by the particular runtime configuration environment.
The method of
myPolicy(E),˜RTEnvironment(E)
The exemplary Prolog expression above evaluates to true if a web service message ‘E’ exists that is not supported by a runtime environment represented by ‘RTEnvironment’ but does satisfy the ‘myPolicy’ security policy. The exemplary Prolog expression above evaluates to false if a web service message ‘E’ does not exist that is not supported by a runtime environment represented by ‘RTEnvironment’ but does satisfy the ‘myPolicy’ security policy. If the Prolog expression ‘myPolicy(E),˜RTEnvironment(E)’ evaluates to false, therefore, then the security policy (106) matches the runtime configuration environment (107). The security policy (106) does not match the runtime configuration environment (107), however, if the Prolog expression ‘myPolicy(E),˜RTEnvironment(E)’ evaluates to true. Readers will note that after the security policy (106) and the runtime configuration environment (107) are represented in predicate logic representations, then determining (404) whether the security policy (106) matches the runtime configuration environment (107) may be carried out merely by evaluating a predicate logic expression using the representations.
The method of
The method of
myPolicy(E),˜RTEnvironment(E)
If the Prolog expression above evaluates to true, then Prolog returns an instance of a web service message that satisfies the expression. That is, Prolog returns an example message that is not supported by the runtime environment represented by ‘RTEnvironment’ but does satisfy the ‘myPolicy’ security policy. Such an example of a message demonstrating that the security policy (106) does not conform to at least one of the configuration parameters of the runtime configuration environment (107) may be useful to a software architect in modifying either the security policy (106) or the runtime configuration environment (107).
Exemplary embodiments of the present invention are described largely in the context of a fully functional computer system for security policy validation for web services. Readers of skill in the art will recognize, however, that the present invention also may be embodied in a computer program product disposed on a computer readable media for use with any suitable data processing system. Such computer readable media may be transmission media or recordable media for machine-readable information, including magnetic media, optical media, or other suitable media. Examples of recordable media include magnetic disks in hard drives or diskettes, compact disks for optical drives, magnetic tape, and others as will occur to those of skill in the art. Examples of transmission media include telephone networks for voice communications and digital data communications networks such as, for example, Ethernets™ and networks that communicate with the Internet Protocol and the World Wide Web as well as wireless transmission media such as, for example, networks implemented according to the IEEE 802.11 family of specifications. Persons skilled in the art will immediately recognize that any computer system having suitable programming means will be capable of executing the steps of the method of the invention as embodied in a program product. Persons skilled in the art will recognize immediately that, although some of the exemplary embodiments described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative embodiments implemented as firmware or as hardware are well within the scope of the present invention.
It will be understood from the foregoing description that modifications and changes may be made in various embodiments of the present invention without departing from its true spirit. The descriptions in this specification are for purposes of illustration only and are not to be construed in a limiting sense. The scope of the present invention is limited only by the language of the following claims.
This application is related to U.S. patent application Ser. No. 11/854,318, filed on Sep. 12, 2007.
