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

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

Hi Polar,

Polar Humenn wrote On 09/06/06 12:25,:
> On Wed, 6 Sep 2006, Anne Anderson - Sun Microsystems wrote:
> 
>> 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.
> 
> 
> Well, I guess that *IS* a client problem! Is the client aware by some 
> standard how much stuff is going to be returned apriori? I guess it will 
> just crash. I realize it's different problem, but with similar 
> circumstances, fair enough. You don't need to address it at the present 
> time.

With other SAML queries, I don't think there is any protocol for letting 
the client specify how much of an answer it can accept.  I believe the 
model is for limits to be set at the messaging level, which will return 
an error to the client if the received message exceeds supported limits.

> 
>>> 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.
>> [snip]
>> 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.
> 
> 
> Whether it is perceived to be stateful (cookie?) or stateless (including 
> same search critera and some progress pointer?) in implementation is 
> immaterial to its stateful or stateless use to the client. You still 
> have protocol questions: If you say that it is just "implementation 
> dependent", then there are still operable "implementation" questions 
> that should be answered for dealing with that PAP. For instance, but not 
> limited to:
> 
> 1. How long is the continuation good for?

PAP implementation-dependent.

> 2. Must the client's next request be the continuation in a consecutive
>     order?

No.  The client chooses whether to continue.  If the client continues, 
then the PAP may or may not accept the continuation, depending on how 
much time has passed, updates to the PAP, etc.  For example, a PAP may 
have a "generation number" that is incremented whenever a policy is 
added, deleted, or modified, and the PAP may include that "generation 
number" in its XACMLPolicyContinuation, along with a pointer to the 
"next" policy that is valid in the current generation.  If the PAP 
receives an XACMLPolicyQuery containing an XACMLPolicyContinuation with 
an out-dated generation number, then the PAP can return an error 
indicating the continuation is stale.  The client can then decide to 
abandon the entire query sequence, or start with a fresh query.

> 3. If so,  when can the client abandon the continuation and get on with
>     the next?

The client can abandon the continuation at any time.  The PAP may also 
abandon support for a given continuation at any time.  But a PAP should 
not return an XACMLPolicyContinuation unless it will typically be able 
to support it for a reasonable time - i.e. long enough for a typical 
client to turn around and request the next continuation.

>     etc.
> 
> I'm just saying that you can write a whole document on this new protocol 
> generated by one element, it should just be thorough.

I don't think there are actually that many cases to deal with here.  I'm 
not trying to design a reliable transaction protocol, just a simple 
mechanism that would support the use case of a relatively stable PAP 
returning multiple blocks of policies to a client.

Regards,
Anne

> 
> Cheers,
> -Polar

-- 
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