[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] A different approach to issue 66
Hal, All, I had a look and WS-XACML does not do this already. WS-XACML specifies WS-Policy assertions with fragments of XACML which can be used to express capabilities and requirements of web services and clients. It's not about requirements and capabilities of an XACML PDP itself. There is a possibility to define which attribute vocabulary these fragments make use of in the form of vocabulary references. Matching of vocabularies is done by means of equality of the vocabulary identifier. This is not sufficient for Rich's use case. Rich's use case was that there is a potentially large set of attributes supported by the PEP, but only a small subset of these attributes are actually used in a PDP. Ideally the PEP should only send this subset. What we need is a method to make fine grained matching of vocabularies defined in terms of sets of XACML attribute identifiers. I was thinking about something like this: Consider a PDP which has two policies, one about printing and another about the personnel roster. <xacml:Policy> <Description>The policy about printing</Description> ... This policy makes use of the following subject attributes: http://example.com/attributes#role the following resource attributes: http://example.com/attributes#resource-type http://example.com/attributes#resource-physical-location </xacml:Policy> <xacml:Policy> <Description>The policy about the roster</Description> ... This policy makes use of the following subject attributes: http://example.com/attributes#role the following resource content schema (qname): {http://example.com/schema/roster}Roster </xacml:Policy> Define a XACML attribute assertion for WS-Policy called <ConsumedXACMLAttributes>: Now, it would be possible for the PDP to publish the following WS-Policy to enable a PEP to work out which attributes it should send: <wsp:Policy> <wsp:All> <wsp:ExactlyOne> <ConsumedXACMLAttributes> <Attribute AttributeId="http://example.com/attributes#role" DataType="..."/> </ConsumedXACMLAttributes> </wsp:ExactlyOne> <wsp:ExactlyOne> <ConsumedXACMLAttributes> <Attribute AttributeId="http://example.com/attributes#resource-type" DataType="..."/> <Attribute AttributeId="http://example.com/attributes#resource-physical-location" DataType="..."/> </ConsumedXACMLAttributes> <ConsumedXACMLAttributes> <ContentElement namespace="http://example.com/schema/roster" localname="Roster"/> </ConsumedXACMLAttributes> </wsp:ExactlyOne> </wsp:All> </wsp:Policy> (Not sure if the way I made <ContentElement> is the prettiest possible solution.) Let's say that the printer PEP is capable of producing the following attributes: http://example.com/attributes#resource-type http://example.com/attributes#resource-physical-location http://example.com/attributes#color-capable http://example.com/attributes#printer-remaining-paper In this case the printer PEP would now that it needs to send the resource type and the physical location attributes in the request, and it would also know that it can skip sending the color-capable and remaining paper attributes since the policies won't make use of those attribute. The roster PEP can instead send the roster in the form of an XML document. Both PEPs would know that they need to send the subject role. I think a solution like this captures Rich's use case much better than the MissingAttributesDetail. Naturally, this is just a sketch for an idea and I am even not sure what the open issues are. But I think the basic approach should be workable. And in most cases I think the WS-Policies could be automatically derived from the XACML policies (except perhaps for the <Content> part, where interpreting xpaths could be difficult). So I propose that: - We fix the MissingAttributesDetail in the XACML 3.0 core spec so it includes the category of the missing attribute, since otherwise it is ambiguous. - We defer the full solution of the problem into a separate profile for WS-Policy (or similar) based attribute publishing policies. Possibly we could define some behavior for which MissingAttributeDetails the PDP should produce, but I cannot think of any meaningful behavior. For instance, in the above examples, when the roster PEP calls the PDP, but there is not a permit decision, should the PDP report the resource-type and physical location attributes as missing? If not, how can the PDP tell that? Regards, Erik Hal Lockhart wrote: > I thought we could do this with WS-XACML. It many need some more explicit conventions, but the ability to specify vocabularies is already there. > > The missing Attributes approach always was sort of crude. Only useful for certain use cases, such as reauthentication with a stronger method. > > Hal > > >> -----Original Message----- >> From: Erik Rissanen [mailto:erik@axiomatics.com] >> Sent: Tuesday, September 30, 2008 10:26 AM >> To: XACML TC >> Subject: [xacml] A different approach to issue 66 >> >> All, >> >> I have given some thought to issue 66, and I think a different approach >> is needed. >> >> This issue concerns coordinating the attribute vocabularies of a PEP and >> policies in a PDP. >> >> Currently the discussion has been about using the "missing attributes" >> in the XACML response, but I think this is the wrong approach: >> >> 1. "Missing attributes" are not sufficiently expressive to be able to >> solve this problem, since the PDP might contain multiple policy "topics" >> which each require different attribute vocabularies. Missing attributes >> would mix up them and it would be hard to make use of the result on the >> PEP side. >> >> 2. "Missing attributes" are inefficient since it means evaluating >> policies and restarting evaluation again, which could go a different >> path in the next round, leading to still more missing attributes. There >> are no good bounds on how many rounds are needed until the process >> terminates. >> >> 3. "Missing attributes" are bad architecture since it mixes two >> fundamentally different problems: attribute coordination and policy >> evaluation. This makes it harder to make independent changes in these >> two issues in the future. >> >> I have another proposal instead. These are just some early thoughts, but >> I am posting them anyway to get the discussion started early. >> >> I suggest we can use WS-Policy for attribute negotiation. We would need >> to define some attribute producer and attribute consumer assertions. >> >> A PEP could publish a WS-Policy which states that it is capable of >> producing some specific XACML attributes. >> >> A PDP could publish a WS-Policy which states that it requires a >> particular XACML attribute vocabulary. This WS-Policy could use the >> WS-Policy structure to express alternative attribute vocabularies if >> there are different XACML policy "topics". For instance, a single PDP >> might contain XACML policies of both printers and email accounts. These >> two "topics" would make use of different attributes and these two >> attibute vocabularies would be published as different alternatives in >> the PDP attribute requirement policy. The PEP for printers would see >> that it can meet the requirements of the printer vocabulary, while the >> email PEP would make use of the other alternative. >> >> I have not worked on any more details, and I have not yet verified that >> this idea would actually work. But if it works, it would have the >> following benefits: >> >> 1. Expressive enought to be able to express full vocabularies in a >> single round of negotiation, so it is more efficient than missing >> attributes. >> >> 2. Does not interfere with XACML policy evaluation schemas or >> functionality, thus splitting up the architecture more cleanly, and any >> runtime overhead is separated into a separate protocol exchange, and >> would not affect each and every XACML response. >> >> 3. The attribute WS-Policy published by the PEP can be used by policy >> editing tools to help XACML policy authoring. >> >> 4. The attribute WS-Policy published by the PDP can be used to minimize >> the set of attributes sent by the PEP in each request. >> >> Some open issues: >> >> How is the PDP side attribute WS-Policy constructed? Ideally it would be >> derived from the XACML policies. At least two possibilities occurs to >> me. A: Extract the attributes which XACML policies refer via attribute >> designators or selectors (selector requirements could be represented as >> XML schema namespaces and elements in the WS-Policy). B: Make >> management/construction of the attribute WS-Policy part of the XACML >> editor, so the XACML policy author can define the vocabulary at the same >> time he defines the XACML policies. >> >> Best regards, >> Erik >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]