ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: How RM+SecureConversation should work for Axis2
Date Wed, 23 Nov 2005 21:55:08 GMT
Hi Chamikara and Ruchith,


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.



----- Original Message -----
From: Chamikara Jayalath
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.




To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message