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)
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" <[EMAIL PROTECTED]> 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 <[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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
