You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Amila Suriarachchi <am...@gmail.com> on 2008/07/20 13:46:36 UTC

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.

Re: Security Manager Interface

Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Amila,

Assuming the security phase passes the msg in *only* after verifying
all signature parts/elements then IMHO your approach is fine.
After the signature verification at the security phase (by rampart or
any other impl), checking the key used to sign at the RM level should
be sufficient.

Thanks,
Ruchith

On Wed, Jul 30, 2008 at 11:45 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Tue, Jul 29, 2008 at 5:40 PM, David Illsley <da...@gmail.com>
> 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
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Sun, Jul 20, 2008 at 9:21 PM, Jaliya Ekanayake
>> > <jn...@gmail.com>
>> > 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: sandesha-dev@ws.apache.org
>> >> 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: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>



-- 
http://blog.ruchith.org
http://wso2.org

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


Re: Security Manager Interface

Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Jul 29, 2008 at 5:40 PM, David Illsley <da...@gmail.com>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
> <am...@gmail.com> wrote:
> >
> >
> > On Sun, Jul 20, 2008 at 9:21 PM, Jaliya Ekanayake <jnekanayake@gmail.com
> >
> > 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: sandesha-dev@ws.apache.org
> >> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>


-- 
Amila Suriarachchi,
WSO2 Inc.

Re: Security Manager Interface

Posted by David Illsley <da...@gmail.com>.
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.
David

On Mon, Jul 21, 2008 at 9:13 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Sun, Jul 20, 2008 at 9:21 PM, Jaliya Ekanayake <jn...@gmail.com>
> 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: sandesha-dev@ws.apache.org
>> 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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


Re: Security Manager Interface

Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Jul 20, 2008 at 9:21 PM, Jaliya Ekanayake <jn...@gmail.com>
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 <am...@gmail.com>
> *To:* sandesha-dev@ws.apache.org
> *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.

Re: Security Manager Interface

Posted by Jaliya Ekanayake <jn...@gmail.com>.
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.
To verify the message is not seen by anybody else, it can be encrypted.

HTH,
Jaliya
  ----- Original Message ----- 
  From: Amila Suriarachchi 
  To: sandesha-dev@ws.apache.org 
  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.