You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Werner Dittmann <We...@t-online.de> on 2005/12/11 12:08:06 UTC
[Policy] Short problem report, a new and more complex example
Sanka, all
Sanka, the detection of the wsp:Optional attribute inside a
PrimitiveAssertion did not work as expected, I fixed it (see
latest checkins).
Unfortunatly this did not fix the wrong behavior of "Optional" handling.
There is no second alternative generated during normalize. After putting
in some trace it seems that PrimitiveAssertion.normalize() is never
called thus is flag is never evaluated - Sanka, can you pls have a
look into that.
A new example shows how to merge two policies. I took the policies
directly from Appendix C.3 of the WS SecurityPolicy specification.
The first policy is a "binding" policy. This binding describes the
overal security behaviour, which flags to set, security token types to
use etc. The second policy, the message policy, describes to which
parts of an actual message need signed, encrypted, etc. Both policies
together form the real security policy. Attached is a pretty-printed
result of this merge. Everybody is invited to have a look and to check
if it is correct (by reading and applying the WS-SecurityPolicy
specification :-) ).
IMHO this separation into "binding" and "message" policy shall be
reflected in the planned implementation for WSS4J. It is also clear that
the security policies do not contain enough information to set-up the
complete security handler: for example the user name(s) to identify the
security tokens (certificates) is missing, maybe some other info
as well.
Regards,
Werner
Re: [Policy] Short problem report, a new and more complex example
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Sanka, Werner,
Sorry about jumping in late...
But ... is there any specific reason that is stopping us from using
the assertions as for the WS-SecPolicy spec to configure the WSS4J
handlers.
IMHO if we try to come up with our own assertions we are going to
loose interoperability ... especially if we are to extract the policy
from the service's WSDL and configure the security handlers based on
the assertions.
What do u guys think?
Thanks,
Ruchith
On 12/12/05, Sanka Samaranayake <ss...@gmail.com> wrote:
> Hi werner, all
>
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> > Sanka, all
> >
> > Sanka, the detection of the wsp:Optional attribute inside a
> > PrimitiveAssertion did not work as expected, I fixed it (see
> > latest checkins).
> >
> > Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> > There is no second alternative generated during normalize. After putting
> > in some trace it seems that PrimitiveAssertion.normalize() is never
> > called thus is flag is never evaluated - Sanka, can you pls have a
> > look into that.
> >
> > A new example shows how to merge two policies. I took the policies
> > directly from Appendix C.3 of the WS SecurityPolicy specification.
> > The first policy is a "binding" policy. This binding describes the
> > overal security behaviour, which flags to set, security token types to
> > use etc. The second policy, the message policy, describes to which
> > parts of an actual message need signed, encrypted, etc. Both policies
> > together form the real security policy. Attached is a pretty-printed
> > result of this merge. Everybody is invited to have a look and to check
> > if it is correct (by reading and applying the WS-SecurityPolicy
> > specification :-) ).
> >
> > IMHO this separation into "binding" and "message" policy shall be
> > reflected in the planned implementation for WSS4J. It is also clear that
> > the security policies do not contain enough information to set-up the
> > complete security handler: for example the user name(s) to identify the
> > security tokens (certificates) is missing, maybe some other info
> > as well.
>
> IMO WSSecurity Policy Assertion language is yet to reach its fullest
> maturity. Mean while, Is it possible to define our own few WSS4J
> specific WSSecurity Policy Assertions which complements the WSSecurity
> Policy Assertion language to fill-in any missing information and use
> them ? In that way all WSS4J configurations can be expressed in a much
> more uniform manner and we can replace them with more appropriate
> WSSecurity Policy Assertions as they become available
>
> >
> > Regards,
> > Werner
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
Ruchith
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Sanka, Werner,
Sorry about jumping in late...
But ... is there any specific reason that is stopping us from using
the assertions as for the WS-SecPolicy spec to configure the WSS4J
handlers.
IMHO if we try to come up with our own assertions we are going to
loose interoperability ... especially if we are to extract the policy
from the service's WSDL and configure the security handlers based on
the assertions.
What do u guys think?
Thanks,
Ruchith
On 12/12/05, Sanka Samaranayake <ss...@gmail.com> wrote:
> Hi werner, all
>
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> > Sanka, all
> >
> > Sanka, the detection of the wsp:Optional attribute inside a
> > PrimitiveAssertion did not work as expected, I fixed it (see
> > latest checkins).
> >
> > Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> > There is no second alternative generated during normalize. After putting
> > in some trace it seems that PrimitiveAssertion.normalize() is never
> > called thus is flag is never evaluated - Sanka, can you pls have a
> > look into that.
> >
> > A new example shows how to merge two policies. I took the policies
> > directly from Appendix C.3 of the WS SecurityPolicy specification.
> > The first policy is a "binding" policy. This binding describes the
> > overal security behaviour, which flags to set, security token types to
> > use etc. The second policy, the message policy, describes to which
> > parts of an actual message need signed, encrypted, etc. Both policies
> > together form the real security policy. Attached is a pretty-printed
> > result of this merge. Everybody is invited to have a look and to check
> > if it is correct (by reading and applying the WS-SecurityPolicy
> > specification :-) ).
> >
> > IMHO this separation into "binding" and "message" policy shall be
> > reflected in the planned implementation for WSS4J. It is also clear that
> > the security policies do not contain enough information to set-up the
> > complete security handler: for example the user name(s) to identify the
> > security tokens (certificates) is missing, maybe some other info
> > as well.
>
> IMO WSSecurity Policy Assertion language is yet to reach its fullest
> maturity. Mean while, Is it possible to define our own few WSS4J
> specific WSSecurity Policy Assertions which complements the WSSecurity
> Policy Assertion language to fill-in any missing information and use
> them ? In that way all WSS4J configurations can be expressed in a much
> more uniform manner and we can replace them with more appropriate
> WSSecurity Policy Assertions as they become available
>
> >
> > Regards,
> > Werner
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
Ruchith
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
Hi werner, all
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka, all
>
> Sanka, the detection of the wsp:Optional attribute inside a
> PrimitiveAssertion did not work as expected, I fixed it (see
> latest checkins).
>
> Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> There is no second alternative generated during normalize. After putting
> in some trace it seems that PrimitiveAssertion.normalize() is never
> called thus is flag is never evaluated - Sanka, can you pls have a
> look into that.
>
> A new example shows how to merge two policies. I took the policies
> directly from Appendix C.3 of the WS SecurityPolicy specification.
> The first policy is a "binding" policy. This binding describes the
> overal security behaviour, which flags to set, security token types to
> use etc. The second policy, the message policy, describes to which
> parts of an actual message need signed, encrypted, etc. Both policies
> together form the real security policy. Attached is a pretty-printed
> result of this merge. Everybody is invited to have a look and to check
> if it is correct (by reading and applying the WS-SecurityPolicy
> specification :-) ).
>
> IMHO this separation into "binding" and "message" policy shall be
> reflected in the planned implementation for WSS4J. It is also clear that
> the security policies do not contain enough information to set-up the
> complete security handler: for example the user name(s) to identify the
> security tokens (certificates) is missing, maybe some other info
> as well.
IMO WSSecurity Policy Assertion language is yet to reach its fullest
maturity. Mean while, Is it possible to define our own few WSS4J
specific WSSecurity Policy Assertions which complements the WSSecurity
Policy Assertion language to fill-in any missing information and use
them ? In that way all WSS4J configurations can be expressed in a much
more uniform manner and we can replace them with more appropriate
WSSecurity Policy Assertions as they become available
>
> Regards,
> Werner
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
running with the new version gives the result (mergeResult_2.xml)
which contains _much_ more elements than the result produced
with the previous version (mergeResult.xml) - both are
semantically the same. IMHO (very humble opinion) the new
version is the correct one if I compare it to the examples shown
in WS SecurityPolicy spec. Every Assertion that could have an
alternative, for example the alogrithm suite could be base256
or some other, are wrapped with Policy/ExactlyOne/All. An
Assertion that triggers an on/off property, for example Timestamp,
is not wrapped (plain property)
See the attached result file - pretty-printed.
Regards,
Werner
Sanka Samaranayake wrote:
> Hi Werner,
>
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka,
>>
>>great. Can you give a short notice on this list after you checked
>>in the fixes?
>
>
> I've just checked in the fixes. PolicyExampleBindingMsg seems to run
> without any errors and produce correct output. Can you please update
> your local copy and see whether everything is ok ?
>
> I've bot subscribed every list on any system I'm working
>
>>with (WSS4J is always available :-) )
>>
>>Regards,
>>Werner
>>
>>
>>Sanka Samaranayake wrote:
>>
>>>On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>>>
>>>
>>>>Sanka,
>>>>
>>>>thanks for the fixes, they work for the simple case.
>>>
>>>
>>>:) !!
>>>
>>>
>>>
>>>>Two problems: I got a compilation problem in PolicyAttachementUtil
>>>>(WSDLConstants.WSDL1_1 does not exist).
>>>
>>>
>>>Fixed !! Now it should compile without any errors
>>>
>>>
>>>
>>>>Second, when trying the second, complex example (merge of two
>>>>policies) I got s stack overflow ....
>>>>
>>>>Can you run the example and check if this also happens on your
>>>>system (I'm running JDK 1.4.2). Thanks.
>>>
>>>
>>>I think its nothing to do with JDK version. Rather it seems to be a
>>>bug in the algorithm which causes an infinite recurrsion. I'll fixed
>>>it ASAP.
>>>
>>>Best,
>>>Sanka
>>>
>>>
>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
running with the new version gives the result (mergeResult_2.xml)
which contains _much_ more elements than the result produced
with the previous version (mergeResult.xml) - both are
semantically the same. IMHO (very humble opinion) the new
version is the correct one if I compare it to the examples shown
in WS SecurityPolicy spec. Every Assertion that could have an
alternative, for example the alogrithm suite could be base256
or some other, are wrapped with Policy/ExactlyOne/All. An
Assertion that triggers an on/off property, for example Timestamp,
is not wrapped (plain property)
See the attached result file - pretty-printed.
Regards,
Werner
Sanka Samaranayake wrote:
> Hi Werner,
>
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka,
>>
>>great. Can you give a short notice on this list after you checked
>>in the fixes?
>
>
> I've just checked in the fixes. PolicyExampleBindingMsg seems to run
> without any errors and produce correct output. Can you please update
> your local copy and see whether everything is ok ?
>
> I've bot subscribed every list on any system I'm working
>
>>with (WSS4J is always available :-) )
>>
>>Regards,
>>Werner
>>
>>
>>Sanka Samaranayake wrote:
>>
>>>On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>>>
>>>
>>>>Sanka,
>>>>
>>>>thanks for the fixes, they work for the simple case.
>>>
>>>
>>>:) !!
>>>
>>>
>>>
>>>>Two problems: I got a compilation problem in PolicyAttachementUtil
>>>>(WSDLConstants.WSDL1_1 does not exist).
>>>
>>>
>>>Fixed !! Now it should compile without any errors
>>>
>>>
>>>
>>>>Second, when trying the second, complex example (merge of two
>>>>policies) I got s stack overflow ....
>>>>
>>>>Can you run the example and check if this also happens on your
>>>>system (I'm running JDK 1.4.2). Thanks.
>>>
>>>
>>>I think its nothing to do with JDK version. Rather it seems to be a
>>>bug in the algorithm which causes an infinite recurrsion. I'll fixed
>>>it ASAP.
>>>
>>>Best,
>>>Sanka
>>>
>>>
>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
Hi Werner,
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka,
>
> great. Can you give a short notice on this list after you checked
> in the fixes?
I've just checked in the fixes. PolicyExampleBindingMsg seems to run
without any errors and produce correct output. Can you please update
your local copy and see whether everything is ok ?
I've bot subscribed every list on any system I'm working
> with (WSS4J is always available :-) )
>
> Regards,
> Werner
>
>
> Sanka Samaranayake wrote:
> > On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> >
> >>Sanka,
> >>
> >>thanks for the fixes, they work for the simple case.
> >
> >
> > :) !!
> >
> >
> >>Two problems: I got a compilation problem in PolicyAttachementUtil
> >>(WSDLConstants.WSDL1_1 does not exist).
> >
> >
> > Fixed !! Now it should compile without any errors
> >
> >
> >>Second, when trying the second, complex example (merge of two
> >>policies) I got s stack overflow ....
> >>
> >>Can you run the example and check if this also happens on your
> >>system (I'm running JDK 1.4.2). Thanks.
> >
> >
> > I think its nothing to do with JDK version. Rather it seems to be a
> > bug in the algorithm which causes an infinite recurrsion. I'll fixed
> > it ASAP.
> >
> > Best,
> > Sanka
> >
> >
> >>Regards,
> >>Werner
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
Hi Werner,
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka,
>
> great. Can you give a short notice on this list after you checked
> in the fixes?
I've just checked in the fixes. PolicyExampleBindingMsg seems to run
without any errors and produce correct output. Can you please update
your local copy and see whether everything is ok ?
I've bot subscribed every list on any system I'm working
> with (WSS4J is always available :-) )
>
> Regards,
> Werner
>
>
> Sanka Samaranayake wrote:
> > On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> >
> >>Sanka,
> >>
> >>thanks for the fixes, they work for the simple case.
> >
> >
> > :) !!
> >
> >
> >>Two problems: I got a compilation problem in PolicyAttachementUtil
> >>(WSDLConstants.WSDL1_1 does not exist).
> >
> >
> > Fixed !! Now it should compile without any errors
> >
> >
> >>Second, when trying the second, complex example (merge of two
> >>policies) I got s stack overflow ....
> >>
> >>Can you run the example and check if this also happens on your
> >>system (I'm running JDK 1.4.2). Thanks.
> >
> >
> > I think its nothing to do with JDK version. Rather it seems to be a
> > bug in the algorithm which causes an infinite recurrsion. I'll fixed
> > it ASAP.
> >
> > Best,
> > Sanka
> >
> >
> >>Regards,
> >>Werner
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
great. Can you give a short notice on this list after you checked
in the fixes? I've bot subscribed every list on any system I'm working
with (WSS4J is always available :-) )
Regards,
Werner
Sanka Samaranayake wrote:
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka,
>>
>>thanks for the fixes, they work for the simple case.
>
>
> :) !!
>
>
>>Two problems: I got a compilation problem in PolicyAttachementUtil
>>(WSDLConstants.WSDL1_1 does not exist).
>
>
> Fixed !! Now it should compile without any errors
>
>
>>Second, when trying the second, complex example (merge of two
>>policies) I got s stack overflow ....
>>
>>Can you run the example and check if this also happens on your
>>system (I'm running JDK 1.4.2). Thanks.
>
>
> I think its nothing to do with JDK version. Rather it seems to be a
> bug in the algorithm which causes an infinite recurrsion. I'll fixed
> it ASAP.
>
> Best,
> Sanka
>
>
>>Regards,
>>Werner
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
great. Can you give a short notice on this list after you checked
in the fixes? I've bot subscribed every list on any system I'm working
with (WSS4J is always available :-) )
Regards,
Werner
Sanka Samaranayake wrote:
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka,
>>
>>thanks for the fixes, they work for the simple case.
>
>
> :) !!
>
>
>>Two problems: I got a compilation problem in PolicyAttachementUtil
>>(WSDLConstants.WSDL1_1 does not exist).
>
>
> Fixed !! Now it should compile without any errors
>
>
>>Second, when trying the second, complex example (merge of two
>>policies) I got s stack overflow ....
>>
>>Can you run the example and check if this also happens on your
>>system (I'm running JDK 1.4.2). Thanks.
>
>
> I think its nothing to do with JDK version. Rather it seems to be a
> bug in the algorithm which causes an infinite recurrsion. I'll fixed
> it ASAP.
>
> Best,
> Sanka
>
>
>>Regards,
>>Werner
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka,
>
> thanks for the fixes, they work for the simple case.
:) !!
>
> Two problems: I got a compilation problem in PolicyAttachementUtil
> (WSDLConstants.WSDL1_1 does not exist).
Fixed !! Now it should compile without any errors
>
> Second, when trying the second, complex example (merge of two
> policies) I got s stack overflow ....
>
> Can you run the example and check if this also happens on your
> system (I'm running JDK 1.4.2). Thanks.
I think its nothing to do with JDK version. Rather it seems to be a
bug in the algorithm which causes an infinite recurrsion. I'll fixed
it ASAP.
Best,
Sanka
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka,
>
> thanks for the fixes, they work for the simple case.
:) !!
>
> Two problems: I got a compilation problem in PolicyAttachementUtil
> (WSDLConstants.WSDL1_1 does not exist).
Fixed !! Now it should compile without any errors
>
> Second, when trying the second, complex example (merge of two
> policies) I got s stack overflow ....
>
> Can you run the example and check if this also happens on your
> system (I'm running JDK 1.4.2). Thanks.
I think its nothing to do with JDK version. Rather it seems to be a
bug in the algorithm which causes an infinite recurrsion. I'll fixed
it ASAP.
Best,
Sanka
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
thanks for the fixes, they work for the simple case.
Two problems: I got a compilation problem in PolicyAttachementUtil
(WSDLConstants.WSDL1_1 does not exist).
Second, when trying the second, complex example (merge of two
policies) I got s stack overflow ....
Can you run the example and check if this also happens on your
system (I'm running JDK 1.4.2). Thanks.
Regards,
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Ruchith,
as I haven't yet read all the doc you mentioned but having
only *one* key pair for reqeustor and *one* for receiver is
IMHO only for demo purposes. During the last weeks or so we had
some questions on th WS4J mailing list how to handle several
clients that have own key pairs, etc.
Well, WSS4J implements a clever method :-) (use signature
request to do encryption) to minimize the number of key pairs
(certificates) a receiver has to store. Nevertheless, a restriction
to just one key pair per requestor and receiver will IMHO not work
in the long run.
On the other hand, defining a user name (alias) and/or the password
support classes (however they are implemented) in a policy that
defines the way to use security seems also wrong to me. Such a
Policy may work for a number of applications of a "client" (client may
be a company or similar organisation) that use some service of another
organisation. Therefore we need IMHO a way that a specific application
can use to define its "alias" and "password" and this should be separate
from the policy.
Am I wrong here and does an "alias" and other info to get the cert
belong to the policy?
Thoughts? Ideas?
Regards,
Werner
Ruchith Fernando wrote:
> Hi Werner,
>
> Oops ... I missed your points you have made in this original mail,
> (which answered my earlier mail:-) ) I noticed we cannot get the cert
> info from the policy.
>
> I had a look at the indigo-plugfest's [1] inteorp doc [2] from MSFT
> where they did use WS-SecPolicy.
>
> Here they are separately mentioning the key aliases in the introp doc [2].
>
> Is this because the requester (client) is assumed to use only *one*
> key pair by default and the receiver (service) is also expected to
> have only *one* key pair? This way they (client and service) really
> have only one fixed option when it comes to keys, hence there's no
> need of expressing them in policy.
>
> Is this practical? Or will this only serve a very simple scenario?
>
> Thanks,
> Ruchith
>
> [1] http://131.107.72.15/ilab/wcfinteroplab.htm
> [2] http://131.107.72.15/ilab/WSSecurity/WCFInteropPlugFest_Security.doc
> [3] http://131.107.72.15/wssecurity/svc/WsSecurity10.svc?wsdl
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka, all
>>
>>Sanka, the detection of the wsp:Optional attribute inside a
>>PrimitiveAssertion did not work as expected, I fixed it (see
>>latest checkins).
>>
>>Unfortunatly this did not fix the wrong behavior of "Optional" handling.
>>There is no second alternative generated during normalize. After putting
>>in some trace it seems that PrimitiveAssertion.normalize() is never
>>called thus is flag is never evaluated - Sanka, can you pls have a
>>look into that.
>>
>>A new example shows how to merge two policies. I took the policies
>>directly from Appendix C.3 of the WS SecurityPolicy specification.
>>The first policy is a "binding" policy. This binding describes the
>>overal security behaviour, which flags to set, security token types to
>>use etc. The second policy, the message policy, describes to which
>>parts of an actual message need signed, encrypted, etc. Both policies
>>together form the real security policy. Attached is a pretty-printed
>>result of this merge. Everybody is invited to have a look and to check
>>if it is correct (by reading and applying the WS-SecurityPolicy
>>specification :-) ).
>>
>>IMHO this separation into "binding" and "message" policy shall be
>>reflected in the planned implementation for WSS4J. It is also clear that
>>the security policies do not contain enough information to set-up the
>>complete security handler: for example the user name(s) to identify the
>>security tokens (certificates) is missing, maybe some other info
>>as well.
>>
>>Regards,
>>Werner
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>>
>
>
>
> --
> Ruchith
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Ruchith,
as I haven't yet read all the doc you mentioned but having
only *one* key pair for reqeustor and *one* for receiver is
IMHO only for demo purposes. During the last weeks or so we had
some questions on th WS4J mailing list how to handle several
clients that have own key pairs, etc.
Well, WSS4J implements a clever method :-) (use signature
request to do encryption) to minimize the number of key pairs
(certificates) a receiver has to store. Nevertheless, a restriction
to just one key pair per requestor and receiver will IMHO not work
in the long run.
On the other hand, defining a user name (alias) and/or the password
support classes (however they are implemented) in a policy that
defines the way to use security seems also wrong to me. Such a
Policy may work for a number of applications of a "client" (client may
be a company or similar organisation) that use some service of another
organisation. Therefore we need IMHO a way that a specific application
can use to define its "alias" and "password" and this should be separate
from the policy.
Am I wrong here and does an "alias" and other info to get the cert
belong to the policy?
Thoughts? Ideas?
Regards,
Werner
Ruchith Fernando wrote:
> Hi Werner,
>
> Oops ... I missed your points you have made in this original mail,
> (which answered my earlier mail:-) ) I noticed we cannot get the cert
> info from the policy.
>
> I had a look at the indigo-plugfest's [1] inteorp doc [2] from MSFT
> where they did use WS-SecPolicy.
>
> Here they are separately mentioning the key aliases in the introp doc [2].
>
> Is this because the requester (client) is assumed to use only *one*
> key pair by default and the receiver (service) is also expected to
> have only *one* key pair? This way they (client and service) really
> have only one fixed option when it comes to keys, hence there's no
> need of expressing them in policy.
>
> Is this practical? Or will this only serve a very simple scenario?
>
> Thanks,
> Ruchith
>
> [1] http://131.107.72.15/ilab/wcfinteroplab.htm
> [2] http://131.107.72.15/ilab/WSSecurity/WCFInteropPlugFest_Security.doc
> [3] http://131.107.72.15/wssecurity/svc/WsSecurity10.svc?wsdl
> On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Sanka, all
>>
>>Sanka, the detection of the wsp:Optional attribute inside a
>>PrimitiveAssertion did not work as expected, I fixed it (see
>>latest checkins).
>>
>>Unfortunatly this did not fix the wrong behavior of "Optional" handling.
>>There is no second alternative generated during normalize. After putting
>>in some trace it seems that PrimitiveAssertion.normalize() is never
>>called thus is flag is never evaluated - Sanka, can you pls have a
>>look into that.
>>
>>A new example shows how to merge two policies. I took the policies
>>directly from Appendix C.3 of the WS SecurityPolicy specification.
>>The first policy is a "binding" policy. This binding describes the
>>overal security behaviour, which flags to set, security token types to
>>use etc. The second policy, the message policy, describes to which
>>parts of an actual message need signed, encrypted, etc. Both policies
>>together form the real security policy. Attached is a pretty-printed
>>result of this merge. Everybody is invited to have a look and to check
>>if it is correct (by reading and applying the WS-SecurityPolicy
>>specification :-) ).
>>
>>IMHO this separation into "binding" and "message" policy shall be
>>reflected in the planned implementation for WSS4J. It is also clear that
>>the security policies do not contain enough information to set-up the
>>complete security handler: for example the user name(s) to identify the
>>security tokens (certificates) is missing, maybe some other info
>>as well.
>>
>>Regards,
>>Werner
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>>
>
>
>
> --
> Ruchith
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Werner,
Oops ... I missed your points you have made in this original mail,
(which answered my earlier mail:-) ) I noticed we cannot get the cert
info from the policy.
I had a look at the indigo-plugfest's [1] inteorp doc [2] from MSFT
where they did use WS-SecPolicy.
Here they are separately mentioning the key aliases in the introp doc [2].
Is this because the requester (client) is assumed to use only *one*
key pair by default and the receiver (service) is also expected to
have only *one* key pair? This way they (client and service) really
have only one fixed option when it comes to keys, hence there's no
need of expressing them in policy.
Is this practical? Or will this only serve a very simple scenario?
Thanks,
Ruchith
[1] http://131.107.72.15/ilab/wcfinteroplab.htm
[2] http://131.107.72.15/ilab/WSSecurity/WCFInteropPlugFest_Security.doc
[3] http://131.107.72.15/wssecurity/svc/WsSecurity10.svc?wsdl
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka, all
>
> Sanka, the detection of the wsp:Optional attribute inside a
> PrimitiveAssertion did not work as expected, I fixed it (see
> latest checkins).
>
> Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> There is no second alternative generated during normalize. After putting
> in some trace it seems that PrimitiveAssertion.normalize() is never
> called thus is flag is never evaluated - Sanka, can you pls have a
> look into that.
>
> A new example shows how to merge two policies. I took the policies
> directly from Appendix C.3 of the WS SecurityPolicy specification.
> The first policy is a "binding" policy. This binding describes the
> overal security behaviour, which flags to set, security token types to
> use etc. The second policy, the message policy, describes to which
> parts of an actual message need signed, encrypted, etc. Both policies
> together form the real security policy. Attached is a pretty-printed
> result of this merge. Everybody is invited to have a look and to check
> if it is correct (by reading and applying the WS-SecurityPolicy
> specification :-) ).
>
> IMHO this separation into "binding" and "message" policy shall be
> reflected in the planned implementation for WSS4J. It is also clear that
> the security policies do not contain enough information to set-up the
> complete security handler: for example the user name(s) to identify the
> security tokens (certificates) is missing, maybe some other info
> as well.
>
> Regards,
> Werner
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
--
Ruchith
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Werner,
Oops ... I missed your points you have made in this original mail,
(which answered my earlier mail:-) ) I noticed we cannot get the cert
info from the policy.
I had a look at the indigo-plugfest's [1] inteorp doc [2] from MSFT
where they did use WS-SecPolicy.
Here they are separately mentioning the key aliases in the introp doc [2].
Is this because the requester (client) is assumed to use only *one*
key pair by default and the receiver (service) is also expected to
have only *one* key pair? This way they (client and service) really
have only one fixed option when it comes to keys, hence there's no
need of expressing them in policy.
Is this practical? Or will this only serve a very simple scenario?
Thanks,
Ruchith
[1] http://131.107.72.15/ilab/wcfinteroplab.htm
[2] http://131.107.72.15/ilab/WSSecurity/WCFInteropPlugFest_Security.doc
[3] http://131.107.72.15/wssecurity/svc/WsSecurity10.svc?wsdl
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka, all
>
> Sanka, the detection of the wsp:Optional attribute inside a
> PrimitiveAssertion did not work as expected, I fixed it (see
> latest checkins).
>
> Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> There is no second alternative generated during normalize. After putting
> in some trace it seems that PrimitiveAssertion.normalize() is never
> called thus is flag is never evaluated - Sanka, can you pls have a
> look into that.
>
> A new example shows how to merge two policies. I took the policies
> directly from Appendix C.3 of the WS SecurityPolicy specification.
> The first policy is a "binding" policy. This binding describes the
> overal security behaviour, which flags to set, security token types to
> use etc. The second policy, the message policy, describes to which
> parts of an actual message need signed, encrypted, etc. Both policies
> together form the real security policy. Attached is a pretty-printed
> result of this merge. Everybody is invited to have a look and to check
> if it is correct (by reading and applying the WS-SecurityPolicy
> specification :-) ).
>
> IMHO this separation into "binding" and "message" policy shall be
> reflected in the planned implementation for WSS4J. It is also clear that
> the security policies do not contain enough information to set-up the
> complete security handler: for example the user name(s) to identify the
> security tokens (certificates) is missing, maybe some other info
> as well.
>
> Regards,
> Werner
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
>
--
Ruchith
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Sanka Samaranayake <ss...@gmail.com>.
Hi werner, all
On 12/11/05, Werner Dittmann <We...@t-online.de> wrote:
> Sanka, all
>
> Sanka, the detection of the wsp:Optional attribute inside a
> PrimitiveAssertion did not work as expected, I fixed it (see
> latest checkins).
>
> Unfortunatly this did not fix the wrong behavior of "Optional" handling.
> There is no second alternative generated during normalize. After putting
> in some trace it seems that PrimitiveAssertion.normalize() is never
> called thus is flag is never evaluated - Sanka, can you pls have a
> look into that.
>
> A new example shows how to merge two policies. I took the policies
> directly from Appendix C.3 of the WS SecurityPolicy specification.
> The first policy is a "binding" policy. This binding describes the
> overal security behaviour, which flags to set, security token types to
> use etc. The second policy, the message policy, describes to which
> parts of an actual message need signed, encrypted, etc. Both policies
> together form the real security policy. Attached is a pretty-printed
> result of this merge. Everybody is invited to have a look and to check
> if it is correct (by reading and applying the WS-SecurityPolicy
> specification :-) ).
>
> IMHO this separation into "binding" and "message" policy shall be
> reflected in the planned implementation for WSS4J. It is also clear that
> the security policies do not contain enough information to set-up the
> complete security handler: for example the user name(s) to identify the
> security tokens (certificates) is missing, maybe some other info
> as well.
IMO WSSecurity Policy Assertion language is yet to reach its fullest
maturity. Mean while, Is it possible to define our own few WSS4J
specific WSSecurity Policy Assertions which complements the WSSecurity
Policy Assertion language to fill-in any missing information and use
them ? In that way all WSS4J configurations can be expressed in a much
more uniform manner and we can replace them with more appropriate
WSSecurity Policy Assertions as they become available
>
> Regards,
> Werner
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: [Policy] Short problem report, a new and more complex example
Posted by Werner Dittmann <We...@t-online.de>.
Sanka,
thanks for the fixes, they work for the simple case.
Two problems: I got a compilation problem in PolicyAttachementUtil
(WSDLConstants.WSDL1_1 does not exist).
Second, when trying the second, complex example (merge of two
policies) I got s stack overflow ....
Can you run the example and check if this also happens on your
system (I'm running JDK 1.4.2). Thanks.
Regards,
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org