On Tue, Jul 29, 2008 at 5:40 PM, David Illsley <[EMAIL PROTECTED]>wrote:
> Trawling through the back of my head, yes I think it's to do with
> RSP/SecureConversation where you need all messages in a given Sequence
> to be associated with a single SecureConversation to prevent a class
> of attacks mention in the RM or SC specs, hence you use the token from
> set-up.
>
> I think Sandesha2 only needs to verify the headers, and can leave the
> body verification to be done at the same time as it would be without
> RM enabled.
Still I am not clear why it has to check for headers (a part of the message)
I implemented this in Mercury as follows.
wsSecurityEngineResult = (WSSecurityEngineResult) engineResultIter.next();
Integer actInt
= (Integer)
wsSecurityEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
if (WSConstants.SIGN == actInt.intValue()) {
Principal principal = (Principal)
wsSecurityEngineResult.get(WSSecurityEngineResult.TAG_PRINCIPAL);
if (principal instanceof WSDerivedKeyTokenPrincipal)
{
String baseTokenId =
((WSDerivedKeyTokenPrincipal) principal).getBasetokenId();
try {
Token usedToken =
this.storage.getToken(baseTokenId);
if (!isEqual(usedToken.getSecret(),
storedToken.getToken().getSecret()))
{
throw new RMSecurityException("Stored
security token is not match with the " +
" security token for this
message");
}
} catch (TrustException e) {
throw new RMSecurityException("Can not get
the security token from the storage");
}
}
}
Here if there is a sign result it checks whether the base key for the signed
key is the key which exchanged at the secure Conversation start up time.
thanks,
Amila.
>
> David
>
> On Mon, Jul 21, 2008 at 9:13 AM, Amila Suriarachchi
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, Jul 20, 2008 at 9:21 PM, Jaliya Ekanayake <[EMAIL PROTECTED]
> >
> > wrote:
> >>
> >> Hi Amila,
> >>
> >> I am not sure what we can achieve by only checking the security token
> >> header of the message.
> >> To verify the message is sent by the person who has the security token,
> >> the entire message should be verified for the signature.
> >
> > yes. Actually these checks are depends on the policy.xml user has given.
> But
> > that verification is done by the Rampart handler.
> > What I thought was at RM level, it is enough to check whether the
> message
> > has used the security token used when creating the sequence.
> >
> > Thanks,
> > Amila.
> >>
> >> To verify the message is not seen by anybody else, it can be encrypted.
> >>
> >> HTH,
> >> Jaliya
> >>
> >> ----- Original Message -----
> >> From: Amila Suriarachchi
> >> To: [email protected]
> >> Sent: Sunday, July 20, 2008 7:46 AM
> >> Subject: Security Manager Interface
> >> hi,
> >>
> >> Sandesha2 SecurityManager has this interface. Here what this message
> Part
> >> parameter means.
> >> /**
> >> * Check that the given element of the message demonstrated proof of
> >> possession of
> >> * the given token. This allows Sandesha to implement the checking
> >> required by the
> >> * RM spec. Proof is normally demonstrated by signing or encrypting
> >> the the given
> >> * part using the token.
> >> * If the elements is not secured with the given token the
> >> SecurityManager must
> >> * throw an exception.
> >> */
> >> public abstract void checkProofOfPossession(SecurityToken token,
> >> OMElement messagePart, MessageContext message)
> >> throws SandeshaException;
> >>
> >> I went through the code and so that always Soap Body and Sequence header
> >> parts are passed to this parameter. Is this means
> >> for a Secure conversation is it required to Sign and Encrypt these
> parts?
> >> Is there any reason why this check is done like this without checking
> the
> >> given Security token value with the Security token value in the
> >> Security Header?
> >>
> >> thanks,
> >> Amila.
> >>
> >> --
> >> Amila Suriarachchi,
> >> WSO2 Inc.
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Amila Suriarachchi,
WSO2 Inc.
