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


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-----
>>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 <samlp:StatusCode> Value XML attribute SHALL be
>>"urn:oasis:names:tc:SAML:2.0:status:Responder" [defined in "
>>SAML to mean: The request could not be performed due to an error on
> 
> the
> 
>>part of the SAML responder or SAML authority].  The content of the
>>second-level status code SHALL be
>>"urn:oasis:names:tc:SAML:2.0:status:TooManyResponses". [defined in
> 
> SAML
> 
>>to mean: "The response message would contain more elements than the
> 
> SAML
> 
>>responder is able to return."]  In this case, the response SHALL
> 
> contain
> 
>>no Assertions.
>>--------------
>>
>>Perhaps it would be acceptable to allow the PAP to return some of the
>>applicable policies, but that seems like asking for trouble.
>>
>>Regards,
>>Anne
>>
>>Anne Anderson - Sun Microsystems wrote On 09/06/06 10:32,:
>>
>>>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

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