OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Issue#39:number of policies to return is too large

Hi Polar,

Polar Humenn wrote On 09/06/06 11:03,:
> Well, if you bring that up, it begs the question, "What if the client of 
> the PAP (it is the PAP, not the PDP, right?) cannot handle all the 
> policies that may be returned?

You are right, it would usually be a PDP that is making the 
XACMLPolicyQuery of a PAP to get policies.  Sorry about that.

If the client can't handle all the policies that may be returned, that 
seems like a client problem.  If the client actually needs all policies 
that match the client's request, then the client simply isn't able to 
deal with its own request; the PAP's response was a correct one for the 
query that was submitted.

In the case of a PAP that is unable to send all requested policies in a 
single XACMLPolicyStatement, there is currently no graceful way to deal 
with that.

> How are you going to maintain state between the consecutive requests?
> "Implementation dependent"? Is that fair? Then why have a standard?

The state would be contained in an implementation-dependent way in the 
XACMLPolicyContinuation element.  The contents need not be standard 
because they will always be used with the same PAP that issued them.

> For functionality, you are probably better off with a separate 
> Request/Reply structure that handles the whole problem.
> In CORBA systems, a pattern has developed for such things. We call them 
> "iterators". (Java people should be familiar with these as well). 
> However, we have the luxury of a request/reply protocol with object 
> references to maintain state. Without explaining IDL, most people can 
> get the idea.
>      interface PAP
>      {
>         PolicyIterator getPolicies(PolicyCriteria crt);
>      };
>      interface PolicyIterator
>      {
>           long how_many();
>           XACMLPolicyList get_next_n(long n)
>                raises (NoneLeft,TooMany);
>           void destroy();
>      };

I think what I am doing is similar.  The XACMLPolicyContinuation element 
lets the client maintain the state, just as an iterator does.  The PAP 
can still be stateless.


> You are probably better off doing something along those lines in the XML 
> to cover all the bases coherently.
> But then again, this problem, since it came up, still begs another 
> question, "What is the acceptable unit of capacity?"
> For instance, I know I can generate one single PolicySet consisting of 
> 30,000 Policies containing 50GB of XML ASCII characters. :^)
> Just my 29,334.85 Turkish Lira,
> -Polar
> On Wed, 6 Sep 2006, Anne Anderson - Sun Microsystems wrote:
>> Problem: What if an XACMLPolicyQuery matches more policies than the 
>> PDP is able to return in a single XACMLPolicyStatement?
>> Proposal:
>> Define a new optional, implementation-dependent element that MAY be 
>> included in an XACMLPolicyQueryType or an XACMLPolicyStatementType.
>> <element name="PolicyQueryContinuation" 
>> type="xacml-saml:PolicyQueryContinuationType" />
>> <complexType name="PolicyQueryContinuationType">
>>    <xs:sequence>
>>      <xs:any namespace="##any" processContents="lax" minOccurs="0"
>>                     maxOccurs="unbounded"/>
>>    </xs:sequence>
>> </complexType>
>> An instance of this element MAY be returned in an 
>> "XACMLPolicyStatementType", along with Policy and/or PolicySet 
>> instances.  If present, it indicates that the XACMLPolicyStatement 
>> does not contain all policies that match the query, and that the PDP 
>> supports a continuation of the response.
>> The request MAY then send another XACMLPolicyQuery containing the 
>> instance of the PolicyQueryContinuation element to obtain more 
>> policies that match the original query.
>> The content and interpretation of the PolicyQueryContinuation element 
>> is completely implementation-dependent.  Support for it is optional.
>> 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]