[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters andalternatives
Ashok Malhotra wrote: > > 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 > > +1 . Regards venu > 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> [mailto:K.Venugopal@Sun.COM] >> Sent: Tuesday, May 29, 2007 7:13 AM >> To: ws-sx@lists.oasis-open.org <mailto: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 >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]