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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
