Hi Colm,
Yeah, the stupidity of it all is not lost on me. Even more amazing is
that someone out there (a USD $32 Billion company) is still using this
for security on an internet facing service. But hey!
I yanked three classes from the WSS4J 1.6:
UsernameToken.java
UsernameTokenSigningAction.java
WSSecUsernameToken.java
Fixed them to compile against the rest of the new code base, hardcoded a
few parameters, and replaced the new UsernameTokenSigningAction with
the old one, using:
<entry key="wss4j.action.map">
<map key-type="java.lang.Integer"
value-type="java.lang.Object>
<!-- replace the UsernameTokenSigningAction -->
<entry key="64"
value-ref=myStuipidUsernameTokenSigningAction"/>
</map>
</entry>
And all's well.
A cleaner job could well be done, but this was quick and sufficient.
Thanks for your help.
--
David Mansfield
Cobite, INC.
On 04/22/2015 10:23 AM, Colm O hEigeartaigh wrote:
Hi David,
The .NET WSE Key derivation code was removed because it was not standard,
and unless I'm mistaken it also sent the password as part of the token,
meaning that it was useless from a security point of view! It should be
very straightfoward in any case to implement your own action/processor
implementations based on old code, and to plug them in if desired.
Colm.
On Tue, Apr 21, 2015 at 7:55 PM, David Mansfield <[email protected]> wrote:
Hi All,
Back in 2013 I implemented a WS Client using CXF that utilized the
STSClient to get a security token. It was painful because all the
configuration was done by hand in the XML (spring) - and none of the
requirements were documented.
The STS uses the ".NET WSE Key derivation" method, that used to be
activated with SIGN_WITH_UT_KEY Action.
Ironically, I built that in April 2013, the same month that the
functionality was being removed from WSS4J for the 2.0 release :-(
Now we are looking to upgrade across the firm to CXF 3.0 (and with it
WSS4J 2.0). This leaves this STS client broken.
Does anyone have any bright ideas about how to solve this? Is there any
documentation that describes what was actually implemented in the first
place, so I can reproduce it?
I've looked at diffs between the old code and new, and it looks like I
should be able to make it work by reimplementing the old
UsernameTokenSigningAction as a custom action.
Regarding custom actions, has the "magic integer" thing from CXF 2 been
replaced in CXF 3 or do we still have to register an implementation class
using the integer constant?
--
Thanks,
David Mansfield
Cobite, INC.
