Hi Chamikara and Ruchith, +1.
The optional SecurityTokenReference imposes some coupling between the implementations, but we can easily implement them so that we don't depend on the existance of the other. Thanks, Jaliya ----- Original Message ----- From: Chamikara Jayalath To: [email protected] Sent: Wednesday, November 23, 2005 1:51 PM Subject: How RM+SecureConversation should work for Axis2 Hi All, Ruchith and I had a small chat on how RM+SecureConversation implementations should work together for Axis2. The base of this discussion was how to use the SecurityTokenReference element (of the CreateSequence message). Let me explain the main ideas we discussed. According to the current WSRM spec, the CreateSequenceRequest message can have an optional SecurityTokenReference element which can be used to refer to a key that should be contained in all the messages that belong to the new sequence. One main thing we clarified was that this element does not force the key exchange to happen using WS-SC. (Key can be exchanged via any mechanism). So we thought the basic conversation should be as follows. 1. Keys are exchanged (e.g. using WS-SC). 2. Client sends a create sequence message. The SecurityTokenReference of this point to the key exchanged in the previous step. 3. Server create a new sequence, and remember that the referenced key should be used for all the messages of the generated sequence. 4. Client receive the CreateSequenceResponse. He also remember that the messages of the new sequence should use the referenced key (of the corresponding CreateSequence message). Here is one way to implement the above scenario. (The way RM and SC handlers should be depoyed in Axis2 is given in the diagram.) At the client side when the RM Out Handler detect a Application message which should be contained in a new sequence, it create a CreateSequence message. The SC Out Handler detect the CreateSequence messsage (using wsa:Action) and pause it. The SC Out hanlder does a RST,RSTR exchange with the server and obtain a key (now both server and client pocess this key). The SC cliend add the SecurityTokenReference part to the body of the CreateSequenceRequest message. This gives a reference to the key obtained in the previous exchange. The message (CreateSequenceRequest) is resumed. The server RM In handler detect the CreateSequenceRequest message and generate a new sequence Id. It send this in a CreateSequenceResponse message, in the outFlow the CreateSequenceResponse message it meet the SC Out Handler which register the (sequenceId,Key) pair (sequenceId is in the message, key can be obtained by finding the reference of the SecurityTokenReference part of the corresponding CreateSequence message, which is in the same OperationContext). The message is allowed to go to the client. At the client side the SC In handler detect the CreateSequenceResponse message (using wsa:Action). It also registers (sequenceId,key) pair. The SC Out handler of the client side will include the registered key in all out going messages of the corresponding sequence The SC In handler of the server side will make sure that this key is included in all the messages of the corresponding sequence. Otherwise it would generate an error. Comments......... Thanks, Chamikara -------------------------------------------------------------------------------- --------------------------------------------------------------------- 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]
