Hi all, Yes, as Paul says, the RM spec tries to protect the RM Sequence, not just any single message exchange. The submitted spec gives a way to embed a SecurityTokenReference in the CreateSequence exchange, and from that point on each of the RM endpoints must ensure that any use of the Sequence also demonstrates proof-of-possession of the token. The patch I submitted defines an interface that should cover creation of the STR, accepting it at the other side, and policing its use throughout the use of the Sequence. The responsibilities are split - the RM layer knows what it needs to do, and an implementation of the interfaces I introduced will give it the security capability it needs.
The new stuff in the WS-RX TC is very similar to the submitted spec, so it fits in nicely with what I have already done. Once we get a new committee draft from the TC (or even better, public review) then it will be easy to get that in there too. Of course, you need an implementation of the interfaces... but I tried to make them generic. We can always tweak them if I made some bad assumptions. Hope that explains what I've done - the comments on the new interfaces should help explain the specifics. Would you folks like to have a call to talk through the code? Cheers Matt "Paul Fremantle" <[EMAIL PROTECTED]> wrote on 26/07/2006 19:53:23: > The latest RM spec (as voted in last week) also has a major piece of > function that means that you can't just drop in Rampart and Sandesha. > The idea is that the Sequence is protected as well as the end service. > In other words, the sequence only accepts messages from the same > source that created the sequence. This requires linkage between the > two modules. > > Paul > > On 7/26/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > The "Security Considerations" section in the WS-RM specification > > (http://xml.coverpages.org/ws-reliablemessaging20030313.pdf) provides few > > recommendations regarding the use of RM and Security. > > > > So it seems to me that we should have some understanding in WS-Security > > regarding the RM specific messages such as create sequence to adhere to > > those recommendations. So mere knowledge in the module level will not be > > enough. > > > > Any thoughts? > > > > Thanks, > > -Jaliya > > > > > > ----- Original Message ----- > > > > From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]> > > To: "Matthew Lovett" <[EMAIL PROTECTED]> > > Cc: <[email protected]> > > Sent: Wednesday, July 26, 2006 12:29 PM > > Subject: Re: RM+Security > > > > > > > On Wed, 2006-07-26 at 12:14 +0100, Matthew Lovett wrote: > > >> Hi Chamikara, > > >> > > >> Sorry for the delay - I was on vacation for a couple of days. I'm afraid > > >> the integration with Rampart is an exercise for the reader (as they say!) > > >> The code I contributed should allow Sandesha to be composed with any > > >> security provider. The interface is fairly generic, and I think it > > >> represents the minimum required for successful integration. Have you any > > >> specific comments about the code? > > >> > > >> The handoff between Security and RM is encapsulated in the > > >> SecurityManager > > >> and SecurityToken interfaces. I included javadoc to explain their > > >> methods, > > >> as well as an overview at the top of each class. > > >> > > >> I would like to see Sandesha composed with Rampart, but I don't know > > >> enough about Rampart to know if it can fulfil these interfaces. > > > > > > I'm not an expert on RM+Security but I'd like to understand why module > > > level composition cannot be sufficient to solve this. That is, I'd like > > > to understand the security requirement from RM point of view to see > > > whether it can be solved by "dropping in" the Rampart module. Can you > > > please give a high level explanation of the bits and how they partake at > > > runtime? > > > > > > Thanks, > > > > > > Sanjiva. > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > -- > Paul Fremantle > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > http://bloglines.com/blog/paulfremantle > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > 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]
