ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <jnekanay...@gmail.com>
Subject Re: RM+Security
Date Thu, 27 Jul 2006 18:47:15 GMT
Hi Matt and Chamikara,

IMHO; better to use Rampart to understand the RM messages and handle the security token management
accordingly as Chamikara have mentioned.

Thanks,
-Jaliya
  ----- Original Message ----- 
  From: Chamikara Jayalath 
  To: sandesha-dev@ws.apache.org 
  Sent: Thursday, July 27, 2006 2:18 PM
  Subject: Re: RM+Security


  Hi Matt,

  Thanx for the explanation and for all the javadocs you have added explaining the code. They
were really helpful :-)

  I accept that there has to be some linkage between Sandesha2 and Rampart modules to get
this working. The problem is what are the work that has to be done by each module.

  It seemed to me that with the SecurityManager interface you have added and with the defiition
of a SecurityToken within sandesha2, the validation of SecurityTokens has been brought inside
Sandesha2. As I understood this means that a real implementaion of the SecurityManager will
have to understand all types of security tokens and it will have to have the capability to
compare two of these security tokens.

  Is this the correct way to go. Wont it be better to make Rampart perform these token management
operations. (there will have to be some linkage logic which allow it to idenfity masages of
a certain sequence). 


  Chamikara



  On 7/27/06, Matthew Lovett < MLOVETT@uk.ibm.com> wrote:
    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" < pzfreo@gmail.com > 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 < jnekanayake@gmail.com> 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" < sanjiva@opensource.lk>
    > > To: "Matthew Lovett" <MLOVETT@uk.ibm.com >
    > > Cc: <sandesha-dev@ws.apache.org >
    > > 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: sandesha-dev-unsubscribe@ws.apache.org
    > > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
    > > >
    > >
    > >
    > > ---------------------------------------------------------------------
    > > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
    > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
    > >
    > >
    >
    >
    > -- 
    > Paul Fremantle
    > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
    >
    > http://bloglines.com/blog/paulfremantle
    > paul@wso2.com
    >
    > "Oxygenating the Web Service Platform", www.wso2.com 
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org 
    > For additional commands, e-mail: sandesha-dev-help@ws.apache.org 
    >


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
    For additional commands, e-mail: sandesha-dev-help@ws.apache.org




Mime
View raw message