[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Explanation of the WS-XACML "Vocabulary" element
Colleagues, At the Face-to-Face in Austin, I was asked to write up an explanation of WS-XACML's "Vocabulary" element on the mailing list. IN THREE SENTENCES ================== The Vocabulary elements in a WS-XACML policy Assertion contain URIs that are associated with policy vocabulary specifications. These specifications collectively must define all the Attributes or XML documents that are referenced by AttributeDesignators or AttributeSelectors in the policy Assertion. WS-XACML does not define any particular format for the vocabulary specifications themselves. IN MORE DETAIL :-) ================== A. WS-XACML ASSERTIONS ====================== A policy "Assertion" in WS-XACML consists of a set of Requirements and a set of Capabilities. -------------------------- | Requirements | | Vocabulary="URI1" | <--defines "role", "level" and their values | <xacml:Policy> | | ... | | role="manager" | | level >= 3 | | ... | | </xacml:Policy> | | Capabilities | | Vocabulary="URI2" | <--defines "resource-id" | Vocabulary="URI3" | <--defines a set of "resource-id" values | <xacml:Apply ...> | | resource-id="salary"| | </xacml:Apply> | -------------------------- Figure 1: XACMLAuthzAssertion example The Requirements are predicates, such as XACML <Apply> expressions or an entire XACML Policy, that define what the issuer of the policy requires from another party (such as a Web Service's clients). A simple Requirements example is shown in Figure 1: 'The subject's "role" Attribute must equal "manager"' and "The subject's "level" Attribute must be at least 3". The Capabilities are also predicates, where these describe what the issuer is willing and able to provide or do for the other party if the Requirements are satisfied. A simple Capabilities example is shown in Figure 1: the identity of a resource (in this case the "salary" datum) that the issuer will send to the client if all the previous Requirements are satisfied. B. VOCABULARY ELEMENTS IN AN ASSERTION ====================================== Each Requirements and Capabilities element has one or more "Vocabulary" elements. The value of a "Vocabulary" element is simply a URI that is associated with a specification that defines one or more of the Attributes and/or Attribute values used in the Requirements or Capabilities element. For example, "URI1" in the example above might be an ID associated with an enterprise organizational specification that defines the "role" and "level" Attributes, their possible values, and what the values mean in terms of the organization. "URI2" might be the URI associated with the XACML 2 Core specification, which defines the "resource-id" Attribute. URI3 might be an ID associated with an enterprise Human Resources department specification that defines values for the "resource-id" Attribute, along with what they mean in terms of HR information items. All of the Attributes and AttributeSelector XPath expressions that are used in a set of Requirements or Capabilities, along with all their possible values, must be defined somewhere in the collection of Vocabulary specifications. C. ASSERTION MATCHING ===================== A Web Service client also has a policy, with its own WS-XACML Assertion(s). In order for their policies (or policy "alternatives") to match, first of all the Vocabularies must match - this ensures that the two parties are talking about the same thing! Each of the Vocabulary URIs in the client's Requirements must be matched by one of the Vocabulary URIs in the Web Service's Capabilities. Each of the Vocabulary URIs in the Web Service's Requirements must match one of the Vocabulary URIs in the client's Capabilities. If these Vocabulary matching requirements are not satisfied, then the client's Assertion is not compatible with the Web Service's Assertion. If the Vocabulary elements match, then each of the client's Requirements must be satisfied by at least one Capability in the Web Service's WS-XACML Assertion. Each of the Web Service's Requirements must be satisfied by at least one Capability in the client's WS-XACML Assertion. This matching is defined in much more detail in the WS-XACML specification draft. D. COMMENTS =========== Every policy has at least an implicit "vocabulary": the set of policy variables that can be used and the values they may take. In XACML, these are - sets of XACML Attributes referenced using AttributeDesignators, - sets of nodes in XML documents that are referenced using AttributeSelectors along with the values that those Attributes or nodes can have. XACML also associates a generic datatype, such as "integer" or "dateTime" with each vocabulary variable. D.1 Where are vocabularies defined? ----------------------------------- - The XACML specifications themselves define a number of standard Attributes, such as "resource-id" and "role", so if these are used in a WS-XACML Assertion, then the associated Vocabulary value would be a URI associated with that XACML specification. - The W3C Platform for Privacy Preferences (P3P) specification defines an XML schema whose instances contain a number of privacy-related nodes; it defines the possible values of those nodes and their meanings, so if the Requirements or Capabilities reference nodes in a P3P instance, then the Vocabulary URI would be a URI associated with the P3P specification. - If an XACML policy references nodes in a "patientRecord" XML document to be submitted in the ResourceContent (as in "the <PatientName> node must match the subject-id Attribute value"), then the institution that uses the "patientRecord" XML document has associated semantics with its nodes, either in some specification. The specification might be an ontology, along with its grounding in the language and practices of the institution. D.2 How do policies specify their vocabularies now? --------------------------------------------------- Currently, in XACML and in WS-Policy, there is no way to state explicitly what the "vocabulary" is: a Policy Enforcement Point (PEP) must be configured to know what Attributes the Policy Administration Point (PAP) expects the PEP to submit, and the PDP must be configured to know how to retrieve any additional Attributes that the PAP's policies reference. WS-Policy simply says the "vocabulary" of a policy is the union of all the Assertions used in various policy alternatives (if policy is viewed as an OR of ANDed Assertions, an alternative is one of the sets of ANDed Assertions). D.3 Why are explicit vocabulary specifications important? --------------------------------------------------------- Authorization and privacy policies often refer to enterprise-specific or domain-specific resource values, role values, etc. Clients and Policy Administration Points must agree on which variables and values they are talking about. If two Assertions or two Policies explicitly state their vocabularies, then the policy matcher can determine whether the client and the service agree on the domain of variables and values they are trying to match. A client can read a potential service's WS-XACML Assertion and determine from the Vocabulary URIs which Attributes and XML documents the policy covers, so can tell if the client knows or has the necessary Attributes or documents. A subtle, but important value, is that an explicit vocabulary definition bounds the domain of a policy: it says "these are the variables and values I care about". It is then possible to define what it means to omit mention of some variable in that domain. Does a policy that does not constrain a particular variable mean that all values for that variable are permitted, or that no values for that variable are permitted? Without an explicit definition of the vocabulary domain, there are an infinite number of variables that are not mentioned, so this is important. For example, in WS-Policy, a particular Assertion's behavior is prohibited by a particular policy alternative if 1) the Assertion is part of the policy's vocabulary, AND 2) the Assertion is omitted from the particular policy alternative But since the only way to include an Assertion in a policy's vocabulary is to include it in at least one policy alternative this means the only way to prohibit an Assertion's behavior in one alternative is to PERMIT it in at least one other policy alternative!!!! D.4 How does a client find the specification associated with a Vocabulary URI? --------------------------------------------------------------------- WS-XACML considers this out-of-scope. Perhaps there is a registry of Vocabularies somewhere. Perhaps the client application is written with a particular set of service providers in mind, and those providers have listed the specifications associated with their vocabularies on their web sites. Perhaps the URI is a resolvable URL that points to the vocabulary specification. We might want to standardize this. D.5 How does a client find the Attributes defined in a Vocabulary specification? --------------------------------------------------------------------- Again, this is out-of-scope for WS-XACML. WS-XACML does not say how a particular vocabulary specification defines its variables; it does not specify the format of a vocabulary specification. The specification might be in machine-readable form, and might include pointers to pluggable AttributeFinder modules. The vocabulary specification might define an ontology used in a standard way by one or more domains. More likely, at least for now, the specification textually describes the required sources for Attributes used in the associated policies, and client application and enterprise PDP programmers design these in. It would be possible to profile one or more ways to specify Vocabularies, but I don't think WS-XACML or XACML should try to take on this task, given that the current way is just to supply a human-readable specification document. D.6 Comments very much welcomed ------------------------------- Regards, Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]