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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
