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]
