RE: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parametersand alternatives

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

We should consider changing the assertion to use a nested Policy rather than a parameter.  

 

<sp:InitiatorToken >

       <sp:X509Token>

            <wsp:Policy>

                    <sp:IncludeToken … </sp:IncludeToken>

            </wsp:Policy>

            <wsp:Policy>

                    <sp:RequireDerivedKeys ... />

                              <sp:RequireKeyIdentifierReference ... />

            </wsp:Policy>

     </sp:X509Token>

   </sp:InitiatorToken >

 

 

All the best, Ashok

---

From: Aditya Athalye [mailto:aditya.athalye@oracle.com]
Sent: Wednesday, May 30, 2007 6:25 AM
To: K.Venugopal@Sun.COM
Cc: ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters and alternatives

 

This is one of the classic examples of an inconsistent intersected policy that we too realized while implementing policy intersection for policies/policy alternatives/assertions. Of course the use case was to check for interoperability between 2 different policies each used for enforcement at the 2 ends of a communication channel.
The default WS-Policy intersection algorithm when applied to security policies/assertions can result in potentially un-interoperable policies. The WS-Policy does talk about domain specific comparison which goes beyond simple QName based comparison, to address this; which is more pertinent in the security assertions case(Non-security assertions may not be affected too much IMO). However, WS-SecurityPolicy does not seem to provide the details on how this processing should be done to make sure policies resulting out of such mutually contradictory assertions/policies are still usable as well as enforceable.
The implementation we did was to do comparison based on assertion attributes (if any as could be done in the example mentioned below), or sub-elements/sub-assertions to make sure policies are even compatible with each other or not, but again it is non-standard, and can change from vendor to vendor, and could hurt interoperability as well.

IMO, WS-SecPolicy also needs to provide a standardized mechanism for intersection/compatibility Out of the Box instead of simply leveraging WS-Policy intersect algo, something which would then become vendor-independent.

Regards
Aditya

Greg Carpenter wrote:

Issue i134

-----Original Message-----

From: K.Venugopal@Sun.COM [mailto:K.Venugopal@Sun.COM]

Sent: Tuesday, May 29, 2007 7:13 AM

To: ws-sx@lists.oasis-open.org

Subject: [ws-sx] New Issue: InlcudeToken Policy Assertion Parameters and

alternatives

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL

THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

*Protocol:* ws-securitypolicy

_http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21362/ws-

secureconversation-1.3-spec-cs-01.pdf_

_http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-

securitypolicy-1.2-spec-cs.pdf_

*Artifact:* spec

*Type:* spec

*Title:*  Policy Assertion Parameters and alternatives

*Description:*

As we know WS Policy does not use Policy Assertion parameters when

intersecting Policy Assertions. IMO this would impact WS Security Policy

to certain extent.

eg:

Alternative A

-------------------------------

<sp:AsymmetricBinding >

<wsp:Policy>

   <sp:InitiatorToken >

       <sp:X509Token sp:IncludeToken = ".....Never">

             <wsp:Policy>

                    <sp:RequireDerivedKeys ... />

                              <sp:RequireKeyIdentifierReference ... />

            </wsp:Policy>

     </sp:X509Token>

   </sp:InitiatorToken >

   <sp:RecipientToken >

       <sp:X509Token sp:IncludeToken = ".......Never">

             <wsp:Policy>

                    <sp:RequireDerivedKeys ... />

                   <sp:RequireKeyIdentifierReference ... />

            </wsp:Policy>

     </sp:X509Token>

   </sp:RecipientToken >

</wsp:Policy>

</sp:AsymmetricBinding >

Alternative B

-------------------------------

<sp:AsymmetricBinding >

<wsp:Policy>

   <sp:InitiatorToken >

       <sp:X509Token sp:IncludeToken = "......Always">

             <wsp:Policy>

                    <sp:RequireDerivedKeys ... />

                              <sp:RequireKeyIdentifierReference ... />

            </wsp:Policy>

     </sp:X509Token>

   </sp:InitiatorToken >

   <sp:RecipientToken >

       <sp:X509Token sp:IncludeToken = "......Always">

             <wsp:Policy>

                    <sp:RequireDerivedKeys ... />

                   <sp:RequireKeyIdentifierReference ... />

            </wsp:Policy>

     </sp:X509Token>

   </sp:RecipientToken >

</wsp:Policy>

</sp:AsymmetricBinding >

When intersected with the default algorithm of the policy framework the

resulting policy would contain mutually contradictory X509Token

parameters. On one hand, the resulting policy would require never to

include X509Tokens while at the same time always requiring to include

X509Tokens. The intersection result would effectively yield an invalid

policy.

Regards,

Venu