- From: Anthony Nadalin <drsecure@us.ibm.com>
- Date: Thu, 17 May 2007 23:54:13 -0500
- To: "David Orchard" <dorchard@bea.com>
- Cc: "Asir Vedamuthu" <asirveda@microsoft.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
- Message-ID: <OF39738DC2.4FB03AD0-ON862572DF.001AD1AF-862572DF.001AEFD0@us.ibm.com>
There is a document in the WSSX-TC called WS-SecurityPolicy Examples that
has some great examples that can chew up processing
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"David Orchard"
<dorchard@bea.com
> To
Anthony Nadalin/Austin/IBM@IBMUS,
05/17/2007 11:47 "Asir Vedamuthu"
PM <asirveda@microsoft.com>
cc
<public-ws-policy@w3.org>,
<public-ws-policy-request@w3.org>
Subject
RE: Bug 4558: Scalability and
performance problems with
expressing allowable nested policy
assertions
Could you provide an example or 2?
thanks,
Dave
From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Thursday, May 17, 2007 9:45 PM
To: Asir Vedamuthu
Cc: David Orchard; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
Subject: RE: Bug 4558: Scalability and performance problems with
expressing allowable nested policy assertions
We have this today, look at a Security Token Service (STS) as implemented
by WS-Trust, and all the security options that are available, I can create
some real nasty assertions that take a lot of processing.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for Asir Vedamuthu <asirveda@microsoft.com>Asir
Vedamuthu <asirveda@microsoft.com>
Asir
Vedamut
hu
<asirve
da@micr To
osoft.c
om> David Orchard
Sent <dorchard@bea.com>,
by: "public-ws-policy@w3.org"
public- <public-ws-policy@w3.org>
ws-poli
cy-requ cc
est@w3.
org
Subject
05/16/2 RE: Bug 4558: Scalability and
007 performance problems with
08:35 expressing allowable nested
PM policy assertions
>The scalability problem is that it may be difficult to list and
>exchange all the possible nested assertions.
>The performance problem is that such a scale may result in slow policy
>processers performing intersection.
We are not sure that a provider or requester will support the myriad of
options that will result in a large number of possible combinations that
one should be worried about. We cannot imagine a practical scenario where
a provider or requestor would expose a myriad of options using the X509
assertion. We think a provider or requester allows little variability
(that reflects what is wired under the hood) and publishes one or some
small number of policy alternatives.
Having said that, we do not actually see a large number of possible
combinations as a problem. While a naïve implementation would, we suppose,
do the full expansion to normal form of all policy alternatives and then
perform n-squared matching. Please note that there are many opportunities
exist for optimization.
OTOH, if you are concerned about malicious providers ... Malicious
providers may provide a policy expression with a large number of
alternatives, a large number of assertions in alternatives or deeply
nested policy expressions. Just like any quality web service
implementation has throttling knobs to limit the size of the message and
other message related parameters, policy implementers need to anticipate
these rogue providers and use a configurable bound with defaults on number
of policy alternatives, number of assertions in an alternative, depth of
nested policy expressions, etc.
Regards,
Asir S Vedamuthu
Microsoft Corporation
-----Original Message-----
From: public-ws-policy-request@w3.org [
mailto:public-ws-policy-request@w3.org.] On Behalf Of David Orchard
Sent: Tuesday, May 15, 2007 5:26 PM
To: public-ws-policy@w3.org
Subject: Bug 4558: Scalability and performance problems with expressing
allowable nested policy assertions
The policy intersection algorithm results in policy assertions with
nesting to
be verbosely expressed with all of the possible nested assertions marked
as
optional="true". One example of this is SecurityPolicy with X509,
detailed in
http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0160.html.
The scalability problem is that it may be difficult to list and exchange
all
the possible nested assertions. The performance problem is that such a
scale
may result in slow policy processers performing intersection.
One counter-arguments are that the number of nested assertions is not
large
enough to warrant this optimization, and that the optimization of adding
optional="true" is sufficient. The general argument of premature
optimization
applies. This would be a close with no action or defer to v.Next.
Proposal 1:
Update the policy intersection algorithm so that an empty policy
assertion
matches a policy assertion with a nested assertion resulting an the same
policy
assertion with a nested assertion.
Proposal 2:
Provide an explicit wildcard to match any nested assertions.
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic07563.gif
- image/gif attachment: ecblank.gif
- image/gif attachment: 21459790.gif
- image/gif attachment: 21116493.gif
Received on Friday, 18 May 2007 04:56:32 UTC