OASIS eXtensible Access Control Markup Language (XACML) TC

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.

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?

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

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();
     };

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

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.

Regards,
Anne

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

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.

>> 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?
2. Must the client's next request be the continuation in a consecutive
    order?
3. If so,  when can the client abandon the continuation and get on with
    the next?
    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.

Cheers,
-Polar

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

Anne Anderson - Sun Microsystems wrote:

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

to that end, it seems like the solution pretty much boils down to: "make 
the request and if anything goes wrong with the 'paging' throw an error 
that is essentially the same as that thrown if something were to go 
haywire with a non paged request."

is this a reasonable simpleton's summary? :o)

b

Yes

Bill Parducci wrote On 09/06/06 15:17,:
> Anne Anderson - Sun Microsystems wrote:
> 
>> 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.
> 
> 
> to that end, it seems like the solution pretty much boils down to: "make 
> the request and if anything goes wrong with the 'paging' throw an error 
> that is essentially the same as that thrown if something were to go 
> haywire with a non paged request."
> 
> is this a reasonable simpleton's summary? :o)
> 
> b

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

On Wed, 6 Sep 2006, Anne Anderson - Sun Microsystems wrote:

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

Yet, the text above this section was filled with ramblings of protocol as 
if it were just "common sense".

It's one thing to specify XACML because it is viewed (or at least I view 
it as) as a representation of access-control policy that is transportable 
between PAPs and different PDPs, leaving the "implementation details" of 
that transport alone.

It's completely other thing to specify a "simple" element in a _protocol_ 
and not cover the bases, or assume others will have the same "common 
sense" about it as you do.

It's funny that we are all in "security" which is supposed to mean things 
like, _availability_, _assurance_, _reliablitity_, yet we punt on those 
things all the time.

Cheers,
-Polar

>It's funny that we are all in "security" which is supposed to mean
things 
>like, _availability_, _assurance_, _reliablitity_, yet we punt on those

>things all the time.

I would think that it is a perfectly sensible thing to punt on those
issues in the context of an authorization language standard.   XACML is
not about reliable messaging, provisioning or assurance.  There is
nothing special about XACML policies in this context - those are just
another XML documents, queried and delivered.   We should not be in the
business of defining metadata on those documents for those purposes - it
would be a waste of time and an unnecessary complication.
Daniel;
 
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Colleagues,

I checked with Eve Maler and Scott Cantor about this, to see what other 
SAML query protocols have done.  Eve says none of the other SAML query 
protocols have tried to solve this problem; she isn't aware of anyone 
running into it either.  Scott thought the implementation-dependent 
approach I proposed was reasonable, but "in practice I'm not sure that 
this is something to be solved above SOAP.  In general, people that care 
about this kind of performance issue build SAX/STAX systems to stream in 
messages, not DOM. In those cases, there's no real value in breaking up 
the envelope. But if you did, it seems like it should be done by 
reinventing TCP on top of SOAP (which is effectively UDP)."

So I propose that we not try to solve this problem.  Our protocol is 
intended for use when at most a few policies will satisfy a particular 
query.  If a PAP has structured its policies such that the size of the 
response is an issue, then the PAP should not be supporting this 
protocol and should be using something else.  If the PAP does support 
the protocol, and still can't return all the applicable policies, then 
the PAP should return an error.  We should define the error in a 
standard way, however.  SAML has already defined errors that seem 
appropriate, and we can simply specify that they are to be used in this 
case.

Proposal: Add following error description to SAML profile:
-----------
If the PAP is unable to return all policies that apply to the request, 
the 

>We should define the error in a standard way, however.  SAML has
already >defined errors that seem appropriate, and we can simply specify
that they >are to be used in this case.
We already have an error - INDETERMINATE value for policy combining.
And an implementation dependent status value may be used in the
response.
Are you talking about defining such an error in the context of SAML
profile only?
Daniel;


_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Hi Daniel,

Daniel Engovatov wrote:
>>We should define the error in a standard way, however.  SAML has
> 
> already >defined errors that seem appropriate, and we can simply specify
> that they >are to be used in this case.
> We already have an error - INDETERMINATE value for policy combining.
> And an implementation dependent status value may be used in the
> response.
> Are you talking about defining such an error in the context of SAML
> profile only?
> Daniel;

Yes.  This issue has to do with an error in the SAML Response to an 
XACMLPolicyQuery.  There would be no way to return an XACML error 
status, since there would be no XACML Response Context involved.  What I 
proposed is, I think, the standard way for this type of error to be 
reported in a SAML protocol.

Regards,
Anne
-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA

I just noted we made a mistake in defining the request context based
query which IMO makes it useless. The intention was (or at least my
intention was) to define a query which would allow the two step XACML
evaluation to be split into to parts. The PAP would do a Target match
(or partial target match) to obtain a small number of potentially
applicable policies. Then the PDP would evaluate the returned policies
to make a decision.

Unfortunately, the way the spec is written it says all the "Applicable"
policies must be returned. Looking at the core spec, this means the
policies must be fully evaluated. I don't really see any usefulness to
evaluating the policies, discarding the results and passing them over to
be evaluated again.

The spec should say that Target matched policies or potentially
applicable policies should be returned.

Hal

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Anne Anderson - Sun Microsystems [mailto:Anne.Anderson@sun.com]
> Sent: Friday, September 08, 2006 9:41 AM
> To: XACML TC
> Subject: Re: [xacml] Issue#39:number of policies to return is too
large
> 
> Colleagues,
> 
> I checked with Eve Maler and Scott Cantor about this, to see what
other
> SAML query protocols have done.  Eve says none of the other SAML query
> protocols have tried to solve this problem; she isn't aware of anyone
> running into it either.  Scott thought the implementation-dependent
> approach I proposed was reasonable, but "in practice I'm not sure that
> this is something to be solved above SOAP.  In general, people that
care
> about this kind of performance issue build SAX/STAX systems to stream
in
> messages, not DOM. In those cases, there's no real value in breaking
up
> the envelope. But if you did, it seems like it should be done by
> reinventing TCP on top of SOAP (which is effectively UDP)."
> 
> So I propose that we not try to solve this problem.  Our protocol is
> intended for use when at most a few policies will satisfy a particular
> query.  If a PAP has structured its policies such that the size of the
> response is an issue, then the PAP should not be supporting this
> protocol and should be using something else.  If the PAP does support
> the protocol, and still can't return all the applicable policies, then
> the PAP should return an error.  We should define the error in a
> standard way, however.  SAML has already defined errors that seem
> appropriate, and we can simply specify that they are to be used in
this
> case.
> 
> Proposal: Add following error description to SAML profile:
> -----------
> If the PAP is unable to return all policies that apply to the request,
> the 

I concur and have marked up the SAML profile working draft to say 
"potentially applicable policies".

Regards,
Anne

Hal Lockhart wrote On 09/14/06 10:58,:
> I just noted we made a mistake in defining the request context based
> query which IMO makes it useless. The intention was (or at least my
> intention was) to define a query which would allow the two step XACML
> evaluation to be split into to parts. The PAP would do a Target match
> (or partial target match) to obtain a small number of potentially
> applicable policies. Then the PDP would evaluate the returned policies
> to make a decision.
> 
> Unfortunately, the way the spec is written it says all the "Applicable"
> policies must be returned. Looking at the core spec, this means the
> policies must be fully evaluated. I don't really see any usefulness to
> evaluating the policies, discarding the results and passing them over to
> be evaluated again.
> 
> The spec should say that Target matched policies or potentially
> applicable policies should be returned.
> 
> Hal
> 
> 
>>

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>>From: Anne Anderson - Sun Microsystems [mailto:Anne.Anderson@sun.com]
>>Sent: Friday, September 08, 2006 9:41 AM
>>To: XACML TC
>>Subject: Re: [xacml] Issue#39:number of policies to return is too
> 
> large
> 
>>Colleagues,
>>
>>I checked with Eve Maler and Scott Cantor about this, to see what
> 
> other
> 
>>SAML query protocols have done.  Eve says none of the other SAML query
>>protocols have tried to solve this problem; she isn't aware of anyone
>>running into it either.  Scott thought the implementation-dependent
>>approach I proposed was reasonable, but "in practice I'm not sure that
>>this is something to be solved above SOAP.  In general, people that
> 
> care
> 
>>about this kind of performance issue build SAX/STAX systems to stream
> 
> in
> 
>>messages, not DOM. In those cases, there's no real value in breaking
> 
> up
> 
>>the envelope. But if you did, it seems like it should be done by
>>reinventing TCP on top of SOAP (which is effectively UDP)."
>>
>>So I propose that we not try to solve this problem.  Our protocol is
>>intended for use when at most a few policies will satisfy a particular
>>query.  If a PAP has structured its policies such that the size of the
>>response is an issue, then the PAP should not be supporting this
>>protocol and should be using something else.  If the PAP does support
>>the protocol, and still can't return all the applicable policies, then
>>the PAP should return an error.  We should define the error in a
>>standard way, however.  SAML has already defined errors that seem
>>appropriate, and we can simply specify that they are to be used in
> 
> this
> 
>>case.
>>
>>Proposal: Add following error description to SAML profile:
>>-----------
>>If the PAP is unable to return all policies that apply to the request,
>>the