|
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 -----
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 < [EMAIL PROTECTED]>
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" < [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]
|
