Thanks again, Ruchith. Your help is very much appreciated. It turns out that the UsernameToken was completely superfluous, since the key was being set directly on the SecurityContextToken after the UsernameToken was. No RST request was actually being sent.
So what would be the simplest way to implement this using Axis2? I need WS-Addressing, and i'm not confident in Axis1's addressing support. Could i use an OperationClient to sign and encrypt the SOAP DOM using WSS4J? (I'm not clear how this might work.) Or do i need to create my own module? Or should i go with the code in SVN HEAD? Thanks! On Tue, 2006-05-30 at 13:30 +0530, Ruchith Fernando wrote: > Let me answer your second question first: > > > constructor > > says "Initializes a new instance of the SecurityContextToken class using the > > security token used to sign the Request Security Token (RST), the security > > token shared by the security token service and the target Web service, and > > the specified identifier." I'm not quite sure that means. > > This means that the client will make a request to a > SecurityTokenService (STS) (defined in the WS-Trust specification) to > establish the security context. > This request is a RequestSecurityToken (RST) request where it will be > signed by the token given as the first argument into the constructor. > In the case where you pass a UsernameToken the RST will be signed > using the UT. The response to RST, RequestSecurityTokenResponse (RSTR) > message will contain the SecurityContextToken that will be used to > derive keys, which will eventually sign/encrypt the actual request > messages to the service. The service will also use the same security > context token to derive keys to verify/ decrypt requests from the > client and sign/encrypt its responses. > > > There's one issue though: The .NET code is creating a SecurityContextToken > > with a UsernameToken as its base. Is there any way to do this with WSS4J? > > This is possible with WSS4J 1.5 and Axis2 (svn head). > > Right now we have an Axis2 module called "rahas" in Axis2 which > supports WS-SecureConversation only. We can use this to carryout the > handshake with the STS and obtain an SCT which can be used to derive > keys to sign and encrypt messages. > Use of the UsernameToken in signing is only in the case of the initial > RST message to the STS and this is supported by "rahas" right now > using the "rampart" handlers internally in "rahas". > > Here [1] you can find some test cases that tests "rahas" > > A word of caution : In a few days the WS-SecureConversation support > will be merged into "rampart" and "rahas" will disappear, which will > allow you to setup your scenario simply with "rampart". > > Thanks, > Ruchith > > [1] > http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/security/rahas/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
