Mailing-List: contact sandesha-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of ruchith.fernando@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nb+lr9Eu4kL50SrmJi4mIsRUpQaUw+FJshXW6ydl87AEPZLMJUo6pxq1/25uPz966JLOnOdtNSMLJ6IlFKrkuOh/HlRFDyA3Vn502XoYv8cNi2XAKIMt3/sYiposYPBnL4L0AJtpenmVHh5GA6frOqhvK0wavjNErUfAgtmo/f8=
Message-ID: <559c463d0607280429k7c4de2a7odd0034750062fb3@mail.gmail.com>
Date: Fri, 28 Jul 2006 16:59:03 +0530
From: "Ruchith Fernando" <ruchith.fernando@gmail.com>
To: "Matthew Lovett" <MLOVETT@uk.ibm.com>
Subject: Re: RM+Security
Cc: "Chamikara Jayalath" <chamikaramj@gmail.com>,
	"Jaliya Ekanayake" <jaliya@apache.org>, sandesha-dev@ws.apache.org,
	"Sanjiva Weerawarana" <sanjiva@opensource.lk>
In-Reply-To: 
 <OFA1ACA9DA.8236FFCE-ON802571B9.0038AC9D-802571B9.003A0DF1@uk.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <559c463d0607280235n58c0d21foc216d19fa5e88641@mail.gmail.com>
	 <OFA1ACA9DA.8236FFCE-ON802571B9.0038AC9D-802571B9.003A0DF1@uk.ibm.com>

Hi Matt,


On 7/28/06, Matthew Lovett <MLOVETT@uk.ibm.com> wrote:
> Hi Ruchith,
>
> Thanks for your note, but I'm afraid that I don't quite follow you.
> Assuming we go with interfaces something like the ones in this note, then
> I think the flow goes something like this:
>
> 1) client invokes service
> 2) RM starts CreateSequence processing, including the following calls:
>         SecurityToken t =
> SecurityManager::getSecurityToken(createSeqContext)
>         OMElement STR = SecurityManager::createSecurityTokenReference(t,
> createSeqContext)
>
> Note that the OMElement may be a placeholder at this point. If you want to
> just establish state in the message context then that would be ok, and you
> could fill in the real detail in the STR during the outbound security
> handler.
>
> 3) RM gets a create sequence response
>         // Note we use the same SecurityToken as earlier, it may have been
> read back in from the tokenRecoveryData....
>         SecurityManager::checkProofOfPossession(bodyElement, t,
> createSeqResponseContext)
>
> 4) RM sends the application message(s)

Yes ... I agree with this flow.

But I was wondering why it is necessary to sandesha to add the
placeholder since anyway the security module will have to be aware of
the CreateSequence message?

For example the security module will have to block a create seqence
message and will have to establish a SecConv context and add  the STR
in the CreateSeq msg to point to the SecConv context that was
established. At this point we can use the message context to share the
toke info with sandesha.

In this case all the information for the STR is with the security
module. Therefore why do we need the placeholder?

Thanks,
Ruchith

>
> Do you think that a part of the interface is missing? I'd assumed that the
> security layer would automagically use the correct token to secure the
> outbound message (as configured in the applications security config), but
> perhaps that was a leap too far. Do we need to add in some other calls to
> allow the SecurityManager to insert a bit more info into the outbound
> message contexts, so the real security handlers know what to do? Is that
> the issue you were trying to get at?
>
> I guess one option would be to call
> SecurityManager::getSecurityToken(appMsgContext) for each outbound
> message, and only use a sequence that matches the correct token. That way
> the security module has had a chance to augment the message context (to
> signal info to the handler), and the RM layer knows that it is using the
> correct sequence. If so, the flow would look more like this:
>
> 1) client invokes service
>         SecurityToken t = SecurityManager::getSecurityToken(appMsgContext)
>         // RM looks for a seq associated with that token, and if there is
> none then it needs to do a create
>
> 2) RM starts CreateSequence processing, including the following calls:
>         OMElement STR = SecurityManager::createSecurityTokenReference(t,
> createSeqContext)
>
> Note that the OMElement may be a placeholder at this point. If you want to
> just establish state in the message context then that would be ok, and you
> could fill in the real detail in the STR during the outbound security
> handler.
>
> 3) RM gets a create sequence response
>         // Note we use the same SecurityToken as earlier, it may have been
> read back in from the tokenRecoveryData....
>         SecurityManager::checkProofOfPossession(bodyElement, t,
> createSeqResponseContext)
>
> 4) RM sends the application message(s)
>         // This gives the security layer a strong hint that we need to use
> this token to secure the message
>         SecurityToken t = SecurityManager::getSecurityToken(appMsgContext)
>         // Look for a sequence associated with this token... this is a
> repeat of stage 1.
>
> Does that make sense? Or have I gone off on a complete tangent?
>
> Matt
>
>
> "Ruchith Fernando" <ruchith.fernando@gmail.com> wrote on 28/07/2006
> 10:35:14:
>
> > Hi Matt, All,
> >
> > I had a look at your patch to figure out how we can integrate this to
> > work with rampart.
> >
> > I'm happy with how its handled in the receiving end but in I have a
> > specific problem with the creation of the CreateSequence message.
> >
> > When Sandesha works with Rampart at the client side, it will not have
> > the knowledge of the STR to include in the CreateSequence message.
> > This is because STR information will only be available in Rampart.
> > IMHO in implementing secure rm with Rampart, Rampart will have to be
> > aware of the CreateSequence message and then insert the STR into the
> > CreateSequence element. And STR info has to be hooked up in the msg
> > cxt to for sandesha2 to use in validating a response.
> >
> > Thoughts?
> >
> > Thanks,
> > Ruchith
> >
> > On 7/28/06, Matthew Lovett <MLOVETT@uk.ibm.com> wrote:
> > > Hi Sanjiva, and everyone else :)
> > >
> > > I think I understand your suggestion - how is this for an approach: at
> > > each point where the RM layer needs to work with a
> > > SecurityContextReference then make it just work with an OMElement.
> > >
> > > I think that leaves the RM layer just aware of _where_ to place the
> STR
> > > (in the create sequence message), and allows the security layer to do
> all
> > > the STR parsing and creation. I agree that this is a cleaner
> separation -
> > > I actually tried it this way at first, but hit some problems while
> > > restructuring the CreateSequence class. I guess I should try harder ;)
> > >
> > > Something like:
> > >
> > > Replace:
> > >         /**
> > >          * Get a security token, from a SecurityTokenReference within
> an
> > > inbound message.
> > >          * This method should not return null, so if the Token cannot
> be
> > > found the implementation
> > >          * should throw an exception.
> > >          */
> > >         public abstract SecurityToken getSecurityToken(String uri,
> String
> > > valueType, MessageContext message)
> > >         throws SandeshaException;
> > >
> > > With
> > >         /**
> > >          * Get a security token, from a SecurityTokenReference within
> an
> > > inbound message.
> > >          * This method should not return null, so if the Token cannot
> be
> > > found the implementation
> > >          * should throw an exception.
> > >          */
> > >         public abstract SecurityToken getSecurityToken(OMElement
> theSTR,
> > > MessageContext message)
> > >         throws SandeshaException;
> > >
> > > And add another method to help create the STR in the first place
> > >         /**
> > >          * Create a SecurityTokenReference, suitable for inclusion in
> the
> > > given message.
> > >          */
> > >         public OMElement createSecurityTokenReference(SecurityToken
> token,
> > > MessageContext message)
> > >         throws SandeshaException;
> > >
> > >
> > > Also, yes you are correct - I need to integrate with a security
> provider
> > > that isn't Rampart. Fortunately (for me) I think that there is no real
> > > conflict of interest here - I believe that it's good for Sandesha to
> be
> > > able to integrate with other security stacks, and I'm all for finding
> a
> > > clean interface that enables that.
> > >
> > > I'm happy to generate another patch, if this seems like the right
> > > direction to take.
> > >
> > > Thanks
> > >
> > > Matt
> > >
> > > Sanjiva Weerawarana <sanjiva@opensource.lk> wrote on 28/07/2006
> 04:07:14:
> > >
> > > > On Thu, 2006-07-27 at 14:47 -0400, Jaliya Ekanayake wrote:
> > > > > 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.
> > > >
> > > > We don't necessarily need for Rampart (or another security provider;
> I
> > > > think that's the need that Matt's trying to address) to understand
> the
> > > > RM messages. Instead if we properly abstract the security function
> we
> > > > should be able to push understanding the tokens to the security
> provider
> > > > and have Sandesha dumbly call the security guy and ask something
> like
> > > > "is this cool with you" and get a simple yes/no answer.
> > > >
> > > > I agree with Chamikara that having Sandesha understand and compare
> > > > security tokens is not a good split.
> > > >
> > > > 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
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
>
>


-- 
www.ruchith.org

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