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/09/05 10:21:42 UTC
Re: Extending WSS4J to the new OASIS specs
All,
after we got positive votes to do a 1.1.0 release I created a
"WSS4J_1_1_0_FINAL" branch in SVN. This branch was created on
Sun Sep 4 at 12:40 MESZ. Support of older namespaces is
availiabe in this branch only.
The next source checkin into the main trunk will contain the first part
of the modifications as described in the mail below.
In this first chunk the configurable namespaces are gone, WSSConfig
is reduced to hold a few parameters only. Some methods that contained
a WSSConfig parameter were modified to remove this parameter because
it was not longer used. Most of these methods are internal methods
anyhow.
Because WSSConfig was not really used that often IMO this does not
affect other implementations.
After doing some more tests an code cleanup I'll checkin the
modifications later this day - be prepared :-).
If someone has time and some free cycles I would appreciate if
you can perform some tests with the modified SW to get an
early feedback in case of problems (due to oversights, typos,
etc.). If all goes well we will start to add the first
WSS 1.1 features after that.
Regards,
Werner
Davanum Srinivas wrote:
> [+1] support only the OASIS V1.0 specs and the relevant namespaces.
> [+1] add the provisional namespaces for the upcoming version
>
> On 8/30/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>All,
>>
>>while looking at the new OASIS WSS specs and the new functionality
>>described I figured out that we have to deal with new namespace
>>URIs again. The namespace URIs shown in the specs are provisional
>>URIs - they will change for the real finished version of the specs.
>>
>>Currently we provide some backward compatibility for old
>>WSS specs. This is cumbersome and error prone. In addition it is not
>>fully implemented because some backward compatibility issues
>>are not really solved. When we are going to introduce new
>>namespace URIs we will get even more problems. Also this
>>backward compatibility complicates the code. I would like to
>>get rid of these code elements. We should point out that these
>>old namespaces were _never_ a real standard.
>>
>>I would propose that for the next version we
>>- support only the OASIS V1.0 specs and the relevant namespaces.
>>- add the provisional namespaces for the upcoming version
>>
>>After the next version of the WSS specs is finished, we do one
>>release with the provisional namespaces and another release (with
>>a new release number) with the then fixed namespace URIs. Doing
>>so we could save a lot of coding while retaining some
>>backward compatibility using a n-1 release.
>>
>>Any ideas? Anyone around that requires the old namespaces?
>>
>>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
Extending WSS4J to the new OASIS specs - first impl of SignatureConfirmation
Posted by Werner Dittmann <We...@t-online.de>.
All,
with the next checkin a first step of the SIgnatureConfirmation
feature of WSS 1.1 is done.
Because of some open issues with the spec this first implementation
assumes:
- generate SignatureConfirmation for every Signature of every
wsse:Security header of the request - there my be several
wsse:Security headers in one request (with different actor/role)
- place all SignatureConfirmation elements together in one
wsse:Security header of the response. This because it is not
necessary that the wsse:Security headers have a one-to-one
relationship with the request headers.
- do not sign SignatureConfirmation yet - here are IMHO some open issues
in the spec
- do not encrypt even if the Signature block of the request was
encrypted. I doubt if such an encryption makes sense.
To enable and test this feature you need to download the source
from SVN (trunk head), set the variable "enableSignatureConfirmation"
to "true" (for the time being it set to "false" by default).
If anybody is going to test this _and_ uses the handler chaining
feature of WSS4J pls ask for additional info. In this case one
specific modification in the WSDD files may be required.
Regards,
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Extending WSS4J to the new OASIS specs - first impl of SignatureConfirmation
Posted by Werner Dittmann <We...@t-online.de>.
All,
with the next checkin a first step of the SIgnatureConfirmation
feature of WSS 1.1 is done.
Because of some open issues with the spec this first implementation
assumes:
- generate SignatureConfirmation for every Signature of every
wsse:Security header of the request - there my be several
wsse:Security headers in one request (with different actor/role)
- place all SignatureConfirmation elements together in one
wsse:Security header of the response. This because it is not
necessary that the wsse:Security headers have a one-to-one
relationship with the request headers.
- do not sign SignatureConfirmation yet - here are IMHO some open issues
in the spec
- do not encrypt even if the Signature block of the request was
encrypted. I doubt if such an encryption makes sense.
To enable and test this feature you need to download the source
from SVN (trunk head), set the variable "enableSignatureConfirmation"
to "true" (for the time being it set to "false" by default).
If anybody is going to test this _and_ uses the handler chaining
feature of WSS4J pls ask for additional info. In this case one
specific modification in the WSDD files may be required.
Regards,
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org