Information about http://cs.umbc.edu/pm4w/papers/parsia18.pdf
Expressing WS Policies in OWL Bijan…
Tags: abstract language, college park, college park md, constructs, dynamics laboratory, formalism, general idea, good sense, isr, jim hendler, maryland college park, maryland network, network dynamics, policy framework, semantics, university of maryland, university of maryland college park, university of maryland college park md, web policy, web service,Pages: 8
Language: english
Created: Tue Apr 19 00:27:36 2005
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Expressing WS Policies in OWL
Bijan Parsia Vladimir Kolovski Jim Hendler
Maryland Information and Dept. of Computer Science Maryland Information and
Network Dynamics Laboratory University of Maryland Network Dynamics Laboratory
University of Maryland College Park, MD 20742 University of Maryland
College Park, MD 20742 College Park, MD 20742
bparsia@isr.umd.edu kolovski@cs.umd.edu
hendler@cs.umd.edu
ABSTRACT language constructs into a logic (e.g., some variant of first
In this paper, we present two translations of the Web Service order logic) we can acquire a clear semantics for the policy
Policy Framework (WS-Policy) into OWL-DL. First, we languages, as well as a good sense of the computational
provide an introduction to WS-Policy and we argue the aspects of the languages.
benefits of using OWL and RDF to express web service If we can map the policy languages into a standardized logic,
policies. Then, we provide two translations from WS-Policy then we can benefit from the tools and general expertise one
to OWL, one of them representing policies as instances, and expects to come with a reasonably popular standard. By
the second one as classes. Finally, we provide a survey of mapping two policy languages into the same background
existing web policy languages and a general idea of their formalism, we will be able to provide some measure of
expressivitiy. interoperability between policies written in distinct
languages. If we are smart in our mapping, we should also be
Categories and Subject Descriptors able use pre-existing reasoners for the standardized logic to
do useful reasoning about policies.
I.2.4 [Artificial Intelligence]: Knowledge Representations
and Formalisms Semantic Web, OWL, RDF, Web Service Our language of choice is the Web Ontology Language,
Policy. OWL [4], and the Resource Description Framework (RDF
[6]). Both RDF and OWL are strict subsets of first order
logic, with the subspecies OWL-DL being a very expressive
General Terms yet decidable subset. OWL-DL builds on the rich tradition of
Performance, Design, Standardization, Languages.
description logics where the tradeoff between computational
complexity and logical expressivity has been precisely and
Keywords extensively mapped out and practical, reasonably scalable
Web services, Policy languages, OWL, RDF, WS-Policy reasoning algorithms and systems have been developed.
In this paper, we have mapped one of the policy languages,
1. Introduction WS-Policy, to OWL-DL. WS-Policy is a policy language
Web services interact with each other by exchanging SOAP being developed by IBM, Microsoft, BEA, and other major
messages. To provide for a robust development and web services vendors and is generally considered to be the
operational environment, services are described using policy language with the most momentum. We have chosen
machine-readable metadata. This metadata serves several two approaches: expressing policies as instances, and
purposes, one of them being describing the capabilities and expressing them as classes. With the latter, we are able to use
requirements of a service -- often called the service policy. our OWL-DL reasoner, Pellet [8] as a policy engine with
In recent years, there have been many different web service analysis services that go far beyond what is usually offered.
policy language proposals, all of them describing languages In the next section we describe our mappings.
with varying degrees of expressivity and complexity.
However, with most current proposals it is difficult to 2. Mappings
determine their expressivity and computational properties as Our implementation consists of two different translations,
most lack formal semantics. One characteristic of the one being where the WS-Policy grammar is encoded in
proposed languages is that they involve policy assertions and OWL and the other where we are trying to capture the
combinations of assertions. For example, a policy might formalism underlying the WS-Policy grammar. In the first
assert that a particular service requires some form of reliable case, individual policies are translated to OWL-DL
messaging or security, or it may require both reliable instances, whereas in the second case they are translated into
messaging and security. Several industrial proposals (e.g., OWL-DL class expressions. This is no surprise as WS-Policy
WS-Policy [13] and Features and Properties [2]) appear to is pretty clearly intended to be a subset of propositional logic
restrict them to a kind of propositional logic with policy and OWL-DL is propositionally closed.
assertions being atomic propositions and the combinations
being conjunction and disjunction. By mapping the policy
2.1. Policies as Instances ontology policy assertions and alternatives are represented
The first ontology is an attempt at designing an OWL with separate OWL classes related with the
ontology that accurately reflects the WS-Policy grammar containsAssertions property. Determining whether a policy
which is originally expressed as an XML Schema. This alternative is supported is done automatically using the
translation essentially captures the syntax of WS-Policy, but results of the policy assertions.
not its semantics. A policy is supported by a requestor of a service if the
As mentioned before, WS-Policy introduces a simple requestor satisfies at least one of the alternatives in the
grammar for expressing policy assertions. These assertions policy. Once the policy alternatives have been evaluated, it
allow developers to add metadata to service description at can be automatically deduced whether a policy is supported
development time or at runtime. Examples of development by the requestor.
time policy would include a specification of which character There are two operators used to express relations between
encodings are supported, or which specifications, and which policies, alternatives and assertions: All and ExactlyOne.
versions of those specifications are supported by the service. These operators are implemented as OWL classes
An example of runtime policy would include interruption in OperatorAll and OperatorExactlyOne in our ontology.
the availability of the Web service due to system OperatorAll requires all the assertions to hold in order for the
maintenance. policy alternative to be satisfied. OperatorExactlyOne
Assertions are the building block of a Web service policy specifies that exactly one of the assertions has to hold in a
and satisfying them usually results in a behavior that satisfies collection of policy alternatives for the policy assertion to be
the conditions for the service endpoints to communicate. A satisfied.
policy assertion is supported by a requestor if and only if the In order to illustrate our work, we present an OWL version
requestor satisfies the requirement, or accommodates the of a policy requiring the web service to use X.509
capability, corresponding to the assertion. Policy assertions certificates or Kerberos tickets as security token types.
usually deal with domain-specific knowledge, and they can
be grouped into policy alternative. An alternative is satisfied
only if the requestor of the service satisfies all of the policy
assertions contained in the alternative. Note that in our
wsse:Kerberosv5TGT
wsse:X509v3
Listing 1. RDF representation of a policy using a WS-Policy grammar expressed in OWL1.
The approach described above gives us a clear way of expressing advantages, as described in Section 2. However, the previous
the syntax of WS-Policy in OWL. This approach has its ontology does not capture the semantics of WS-Policy, so it is
1
The ontology capturing the WS-Policy grammar is available at
http://mindswap.org/dav/ontologies/ws-policy_instance.owl
difficult, for example, to determine whether two policies are Handling wsp:ExactlyOne might be trickier, depending on the
consistent with each other. The following translation does a better interpretation of the construct. There are two possible
job of capturing the semantics of WS-Policy. interpretations:
a) wsp:ExactlyOne means that a policy is supported
by a requester if and only if the requester supports
at least one of the alternatives in the policy. In the
previous version of WS-Policy there was a
2.2. Policies as Classes wsp:OneOrMore construct capturing this meaning.
In such case, the wsp:ExactlyOne is an inclusive
Our second translation maps the WS-Policy formalism directly in
OR , and can be mapped using owl:unionOf.
OWL. We accomplish that by translating the WS-Policy
constructs from a normal form policy expression into OWL b) The other interpretation is that wsp:exactlyOne
constructs. A normal form policy expression is a straightforward means that only one, not more, of the alternatives
XML Infoset representation of a policy, enumerating each of its should be supported in order for the requester to
alternatives that in turn enumerate each of its assertions. support the policy. This is supported by [13],
Following is a schema outline for the normal form of a policy where it's stated that although policy alternatives
expression: are meant to be mutually exclusive, it cannot be
decided in general whether or not more than one
alternative can be supported at the same time. Our
translation covers this more complicated case.
[ [ ... ]* ]* Wsp:ExactlyOne can be translated in OWL in the following way:
for n different policy assertions, expressed as OWL classes
themselves, wsp:ExactlyOne is the class expression consisting of
the members of each separate policy class that do NOT also
Listing 2. Normal form of a policy expression belong to another policy class. In OWL terms, it is the union of all
of the classes with the complement of their pair-wise
Policy expressions can also be represented in more compact
intersections. Because of the pair-wise intersections there is a
forms, using additional operators such as wsp:Optional, however
quadratic increase in the size of the OWL construct that is used as
as shown in [13] the policy expressions can all be expanded to
a mapping for wsp:ExactlyOne. Following is a table summarizing
normal form. Therefore we only provide a mapping of the
both of the translations:
constructs used in a normal form policy expression:
wsp:ExactlyOne and wsp:All.
First, we map policy assertions directly into OWL-DL atomic Table 1. Mapping WS-Policy to OWL
classes (which correspond to atomic propositions). Though WS- WS-Policy Construct OWL Expression
Policy assertions often have some discernible substructure, it is
not key to their logical status in WS-Policy. Or rather, that Wsp:All (policies A intersectionOf ( A B)
substructure is idiosyncratic to the assertion set, rather than being and B)
a feature of the background formalism. So a general WS-Policy
engine must be adapted to deal with their structure, if it is to do
so. The WS-Policy specification asserts: Wsp:ExactlyOne intersectionOf(
(policies A and B) complementOf (intersectionOf (A B))
"Assertions indicate domain-specific (e.g., security,
transactions) semantics and are expected to be defined unionOf (A B)
in separate, domain-specific specifications." )
It seems unfortunate that each domain-specific specification
comes with its own domain specific syntax. If we are to capture
the semantics of each assertion language, we must separately map In order to illustrate how the mapping of wsp:All and
each assertion language into OWL. Our default of treating each wsp:ExactlyOne works, we present a sample policy ontology.
assertion as a simple atomic proposition is reasonable for general The general WS-Policy Assertions are stored as OWL classes, for
policy manipulation, since a general purpose policy engine will example there is a SecurityTokenType class with subclasses
work roughly the same way. KerberosTicket, UsernameToken and X509Certificate. Other
assertions are stored, too: Language, Messaging, SpecVersion and
Mapping wsp:All to an OWL construct is straightforward because TextEncoding. Figure 1 illustrates the WS-Policy class hierarchy.
wsp:All means that all of the policy assertions enclosed by this
operator have to be satisfied in order for communication to be
initiated between the endpoints. Thus, it is a logical conjunction
and can be represented as an intersection of OWL classes. Each of
the members of the intersection is a policy assertion, and the
resulting class expression (using the operator owl:intersectionOf)
is a custom-made policy class that expresses the same semantics
as the WS-Policy one.
Having stored a part of WS-PolicyAssertions [14] as OWL
classes, now it's possible to develop our own custom policies. For
example, say we wanted a policy such that the requestor supports
Kerberos tickets and reliable messaging. Those two conditions
can be represented as two assertions in a policy alternative,
implying that they can be mapped to an owl:intersectionOf. The
corresponding OWL expression shown in Figure 2.
Figure 1. Sample Policy Ontology
Figure 2. Wsp:All representation in OWL
For the wsp:ExactlyOne example, we consider a policy that
expects the requestor to provide either a Kerberos ticker, or an
X509 certificate, but not both. In OWL, it would be represented
by the class expression composed of the elements that are
exclusive to KerberosTicket and X509Certificate. Figure 3
represents a serialization of the class expression in RDF/XML.
Figure 3. Wsp:ExactlyOne representation in OWL
since Retry-On-Failure is a subclass of Reliable, our OWL-DL
reasoner [8] classifies Retry-On-FailureUsernamePolicy as a
2.3. Policy processing subclass of GeneralReliabilityUsernamePolicy , meaning that any
user that supports the latter will also support the former.
One of our arguments for expressing policies using OWL was the
ability to reason about policy containment whether the
requirements for supporting one policy are a subset of the
requirements for another. That would allow us to be more flexible
in determining whether a particular requestor supports a policy,
in the cases where the requestor supports a superset of the
requirements established by the policy.
Figure 5. Example of policy incoherence
The above figure is an example of Swoop showing an incoherent
Figure 4. Example of policy containment
policy. IncoherentPolicy selects two policy alternatives from an
wsp:ExactlyOne, which, according to our current translation is
In the previous figure, Retry-On-FailureUsernamePolicy is an forbidden. Note that Swoop displays an explanation of the
intersection of Retry-On-Failure and UsernameToken. However, incoherence, which can aid in repairing the policy.
In general, we get the following inferences out of the box: format that can be retrieved automatically and interpreted easily
1) policy inclusion ( if x meets policy A then it also meets by user agents. P3P user agents allow users to be informed of site
policy B; a.k.a., A rdfs:subClassOf B); practices (in both machine- and human-readable formats) and to
automate decision-making based on these practices when
2) policy equivalence (A owl:equivalentTo B); appropriate. According to [15], there exists a data-centric
3) policy incompatibility (if x meets policy A then it relational semantics for P3P in which a P3P policy is modeled as
cannot meet policy B; a.k.a, A owl:disjointWith B); a relational database. This simple semantics allows us to express
P3P using RDF.
4) policy incoherence (nothing can meet policy A; a.k.a.,
A is unsatisfiable) 3.2. The Features and Properties architecture [2] originates
from SOAP 1.2, and was integrated into WSDL 2.0 in order to
5) policy conformance (x meets policy A; a.k.a, x rdf:type
support the SOAP-specific concepts. Afterwards the architecture
A)
was further expanded in order to allow Features to be more
Some care must be taken given the open world semantics of abstract. Simply put, a Feature identifies a piece of functionality,
OWL. For example, an OWL reasoner does not assume that identified by a URI. An example of a Feature would be
because it cannot prove that x conforms to policy A, that x does encryption. Properties are the parameters of a Feature, also
not conform to policy A. It is unclear what the WS-Policy authors identifiable by a URI. For an encryption feature, property might
intend, though a closed world assumption is not unlikely. be the algorithm used, part of message encrypted, etc. Features &
However, even if there is a closed world assumption on WS- Properties are similar to WS-Policy in terms of expressivity, with
Policies, we can handle at least some of those cases by adding one exception they lack operators for combining policy
explicit disjoint statements at translation time. assertions. It is argued at [3] that adding a choose one/all
One futher reasoning service supported by Pellet, and integrated operators (called combinators) will prove to be useful in
with Swoop, is explanations for inconsistencies,[16] which can be expressing higher-level semantics combining multiple policies.
used to help debug policy incompatibility, incoherence, and the 3.2. WS-Policy [13] provides a general-purpose model and syntax
like. As we add further explanation capability to our systems, this to describe and communicate the policies of a Web service. It
debugging power will grow. specifies a base set of constructs that can be used and extended by
Thus we see that with a fairly simple mapping, we can use an off other Web service specifications to describe a broad range of
the shelf OWL reasoner as a policy engine and analysis tool, and service requirements and capabilities. WS-Policy introduces a
an off the shelf OWL editor as a policy development and simple and extensible grammar for expressing policies and a
integration environment. OWL can also used to develop domain processing model to interpret them. The policy assertions are
specific assertion languages (essentially, domain Ontologies) with expressing using XML and the grammar itself is specified with
a uniform syntax and well specified semantics. We can also XML Schema.
experiment with extensions to WS-Policy, by using more By using OWL we increase the expressiveness of the WS-Policy
expressive constructs from OWL at the policy language, as well representation and it will simplify the interaction between any
as the assertion language, level. We can play with extensions new protocols on one hand, and WS-Policy and WSDL on the
before having to write a yet another processor for them. Of other hand. By using OWL/RDF we do not need to focus on the
course, if it turns out that we really want to restrict ourselves to a ways in which the policy is attached to the web service, instead
very inexpressive subset, then we may still want to build specific we can concentrate on analyzing the policy itself.
reasoners and processors that are tuned for that sublanguage. But
Also, WS-Policy uses an open content model on policy assertions
there again, our tools can help us. Pellet does expressivity
to provide extensibility, and the usage of OWL and RDF can
analysis of ontologies, so can help determine what logic we are
provide more expressiveness by way of subclass and subproperty
really using and the price of extensions.
constructs re-using of derived policy assertions.
Furthermore, ontology development techniques can be useful for
[10] provides a comparison of XML and RDF in terms of
policy development as well. Most human generate ontology
expressing WS-Policies. It also provides arguments for usage of
develop iteratively, with specializations added to the class tree
RDF to represent WS-Policy by describing how RDF meets
over time. Similarly, we can build up our policies from more
document merging and extensibility goals described in the WS-
general ones. A general policy could be very restrictive, setting
Policy specifications. To support this, the paper presents an RDF
tough guidelines for all of a companies policies.
schema for representing web service policies upon which our
Finally, given a similar style mapping for another policy language policies as instances mapping was built.
(say, Features and Properties, described in the next section) we
3.4. KaOS Policy and Domain Services [11] use ontology
can do policy analysis and integration across policy languages.
concepts encoded in OWL to build policies. These policies
constrain allowable actions performed by actors which might be
3. Other Policy Languages clients or agents. The KAoS Policy Service distinguishes between
In this section we provide a quick overview of the state-of-the-art authorizations (i.e., constraints that permit or forbid some action)
in web service policy specification, by looking at the policy and obligations (i.e., constraints that require some action to be
languages presented at [12]. To the best of our knowledge, they performed when a state- or event-based trigger occurs, or else
are sorted by increasing level of expressivity, even though lack of serve to waive such a requirement). The applicability of the
formal semantics and analysis hampered our effort to provide a policy is defined by a class of situations which definition can
fully correct listing. The list follows: contain components specifying required history, state and
3.1. The Platform for Privacy Preferences Project (P3P) [9] currently undertaken action. In the case of the obligation policy
enables Web sites to express their privacy practices in a standard the obligated action can be annotated with different constraints
restricting possibilities of its fulfillment. KAoS services have translation is correct, we have provided a formal semantics for
been extended to work equally well with both agent-based (e.g., WS-Policy. At worst, we have exposed some of the assumptions
CoABS Grid, Cougaar, SFX, Brahms) and traditional clients on a and ambiguities about the current specification.
variety of general distributed computing platforms. We have demonstrated that an OWL-DL reasoner provides useful
3.5. WSPL services for policy analysis, including policy containment,
WSPL[14] is being developed at Sun Microsystems. The Web incompatibility, conformance, and incoherence. We expect that
Services Policy Language (WSPL) is suitable for specifying a having such services available will raise the bar for policy engines
wide range of policies, including authorization, quality-of-service, overall.
quality-of protection, reliable messaging, privacy, and In our future work, we intend to provide a standard mapping of all
application-specific service options. WSPL is of particular the current WS-Policy assertion languages with some structural
interest in several respects. It supports merging two policies, fidelity. We also plan to attempt translations of at least parts of
resulting in a single policy that satisfies the requirements of both, the other policy languages we described in order to get a more
assuming such a policy exists. Policies can be based on precise sense of their expressivity. If they cannot be mapped into
comparisons other than equality, allowing policies to depend on OWL, we intend to isolate the incompatible expressivity in order
fine-grained attributes such as time of day, cost, or network to determine whether there are reasonable extensions to OWL that
subnet address. By using standard data types and functions for could accommodate it.
expressing policy parameters, a standard policy engine can Finally, we intend to further develop our tools as WS-Policy
support any policy. The syntax is a strict subset of the OASIS processing tools. We shall investigate the gap between general
eXtensible Access Control Markup Language (XACML [5], purpose tools like Pellet and Swoop and things tuned for WS-
discussed below) Standard. WSPL has been implemented, and is Policy. For example, our explanation facility might do better for
under consideration as a standard policy language for use with WS-Policies if it knew the characteristic structure of their
web services. translations.
3.6. XACML provides a policy language which allows
administrators to define the access control requirements for their
application resources. The language and schema support include 5. ACKNOWLEDGEMENTS
data types, functions, and combining logic which allow complex This work was completed with funding from Fujitsu Laboratories
(or simple) rules to be defined. XACML also includes an access of America- College Park, Lockheed Martin Advanced
decision language used to represent the runtime request for a Technology Laboratory, NTT Corp., Kevric Corp., SAIC,
resource. When a policy is located which protects a resource, National Science Foundation, National Geospatial-Intelligence
functions compare attributes in the request against attributes Agency, DARPA, US Army Research Laboratory, NIST, and
contained in the policy rules ultimately yielding a permit or deny other DoD sources.
decision. It is a powerful language, able to also express first order
and higher order functions.
3.7. Rei [7] is a policy specification language based on a 6. REFERENCES
combination of OWL-Lite, logic-like variables and rules. It
allows users to develop declarative policies over domain specific [1] Anderson, A. H. An Introduction to the Web Services Policy
ontologies in RDF, DAML+OIL and OWL. Rei allows policies to Language. Sun MicroSystems.
be specified as constraints over allowable and obligated actions http://research.sun.com/projects/xacml/Policy2004.pdf
on resources in the environment. A distinguishing feature of Rei
is that it includes specifications for speech acts for remote policy [2] Daniels, G. Comparing Features / Properties and WS-Policy.
management and policy analysis specifications like what-if W3C Workshop on Constraints and Capabilities for Web
analysis and use-case management. As Rei is geared towards Servies. Redwood Shoes, CA, USA, Oct 12 -13, 2004.
distributed environments, it also includes conflict resolution [3] Daniels, G. Features and Properties Musings. www-ws-
specifications like modality preferences or priority assignments desc@w3.org mailing list, October 2003.
between policies or between individual rules of a policy. http://lists.w3.org/Archives/Public/www-ws-
desc/2003Oct/0144.html
Having produced a mapping for WS-Policy to OWL, we have [4] Dean, M. and Schreiber G. OWL Web Ontology Language.
shown that also Features and Properties and P3P can also be Reference W3C Recommendation,
mapped, since they are less expressive than WS-Policy. We plan http://www.w3.org/tr/owl-ref/. Feb 2004.
to focus on the more expressive languages (WSPL, XACML,
Rei) in the future, to determine how much of them can be mapped [5] Godik, S., and Moses,T., eds. OASIS eXtensible
into OWL, or whether we must move to a more expressive Access Control Markup Language (XACML) Version
language (like SWRL), or out of first order logic altogether. We 1.1. Oasis Committee Specification, http://www.oasis-
believe that translation considerations for existing and used policy open.org/committees/download.php/4103/cs-xacml-
languages should be a factor in future extensions to OWL. specification-1.1.doc. 24 July 2003.
4. Conclusion [6] Lassila, O. and Swick, R. Resource Description Framework
We have presented a translation of the base formalism of WS- (RDF) Model and Syntax Specification. W3C
Policy into OWL-DL and described how those translations can be recommendations, WWW Consortium. Cambrigde,MA,
used for policy analysis, processing, and development. If our USA. Feb 1999.
[7] Kagal, L. et al. A policy Language for a Pervasive [12] W3C Workshop on Constraints and Capabilities for Web
Computing Environment. In Collection, IEEE 4th Services. Redwood Shores, CA, USA. Oct 12-13, 2004.
International Workshop on Policies for Distributed Systems http://www.w3.org/2004/06/ws-cc-cfp.html.
and Networks. June 2003.
[13] Web Services Policy Framework (WS-Policy). http://www-
[8] Pellet OWL-DL reasoner, 106.ibm.com/developerworks/library/specification/ws-
http://www.mindswap.org/2003/pellet. polfram/.
[9] Platform for Privacy Preferences Project. [14] Web Services Policy Assertions Language. http://www-
http://www.w3.org/P3P/ 106.ibm.com/developerworks/library/ws-polas/
[10] Prud'hommeaux, E. RDF for Web Service Assertions. W3C [15] Yu, T., Li N., and Anton A.L. A formal semantics for P3P.
Workshop on Constraints and Capabilities for Web Services. ACM Workshop on Secure Web Services, October 29 2004,
Redwood Shores, CA, USA. Oct 12-13, 2004. Fairfax VA, USA.
[11] Uszokand, A. and Bradshaw, J. KAoS Policies for Web [16] Parsia, B., Sirin. E., Kalyanpur, A. Debugging OWL
Services. W3C Workshop on Constraints and Capabilities Ontologies, In The 14th International World Wide Web
for Web Servies. Redwood Shoes, CA, USA, Oct 12 -13, Conference (WWW2005), Chiba, Japan, May 2005.
2004.