Hi Jamie,

Since you are using rampart/C only in the client side the following
quick fix can be done.

You need to build the source code with the little change given below.

1.Open the file,
  rampart_source_dir/src/util/rampart_sec_header_processor.c.

2.Go to the rampart_shp_process_timestamptoken() method.

3.Do the following change to the code fragment below.

    if(!ts_node)
    {
        if(rampart_context_is_include_timestamp(rampart_context,env))
        {
            AXIS2_LOG_INFO(env->log, "[rampart][shp] Timestamp is not in
the message");
            
            /*return AXIS2_FAILURE;*/
            return AXIS2_SUCCESS;
        }else{
            return AXIS2_SUCCESS;
        }
    }

You just need to comment returning AXIS2_FAILURE and instead return
AXIS2_SUCCESS as I have shown above.
Hope This works for you.

-Manjula.



On Wed, 2007-08-08 at 11:47 +0100, Jamie Lyon wrote:
> At present the services are running on Axis1/Java + WSS4J.
> 
> Thanks,
> Jamie
> 
> 
> > -----Original Message-----
> > From: Kaushalye Kapuruge [mailto:[EMAIL PROTECTED]
> > Sent: 08 August 2007 11:48
> > To: Apache AXIS C Developers List
> > Subject: Re: Error: "Key Reference Info is mismatch with policy"?
> > 
> > Hi Jamie,
> > In Rampart/C v 0.90, we had implemented it in such a way that user can
> > specify different policies for incoming and outgoing messages. But
> after
> > that we changed it to be compatible with other implementations, mainly
> > due to the interoperability between different policy frameworks. I
> also
> > agree with you, having such a flexibility in configurations can be
> > useful.  So we will try to introduce this behavior in Rampart/C.
> > BTW, I'd like to know if possible, which kind of framework you have
> used
> > to deploy services? Is it Axis2/Java + Rampart/Java or any other
> > implementation. (This feature is not in Rampart/J though).
> > Cheers,
> > Kaushalye
> > 
> > Jamie Lyon wrote:
> > > Unfortunately the service I am interacting with requires that the
> > > timestamp is included when sending a message to it, but does not
> send a
> > > timestamp in the response. So yes, an optional timestamp is a
> > > requirement for interaction, without it I cannot do any
> communication at
> > > all.
> > >
> > > A workaround for the IncludeTimestamp case would be perfectly
> > > acceptable, I don't (at least currently) require anything else to be
> > > optional.
> > >
> > > If there's a simple way of doing this temporarily, that will be
> fine.
> > >
> > > Thanks,
> > > Jamie
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Manjula Peiris [mailto:[EMAIL PROTECTED]
> > >> Sent: 08 August 2007 16:37
> > >> To: Apache AXIS C Developers List
> > >> Subject: RE: Error: "Key Reference Info is mismatch with policy"?
> > >>
> > >> Hi Jamie,
> > >>
> > >> Please see my comments inline.
> > >>
> > >>
> > >> On Wed, 2007-08-08 at 09:48 +0100, Jamie Lyon wrote:
> > >>
> > >>> Excellent, that's fixed that problem.
> > >>>
> > >>> You will have to excuse my simple questions; I've not used
> ws-policy
> > >>> before.
> > >>>
> > >>> Is it possible to specify that the client has to include a
> timestamp
> > >>>
> > > in
> > >
> > >>> the sent message, but may or may not receive one back?
> > >>>
> > >> In the current implementation it is not possible. Because
> > >> <sp:Includetimestamp> assertion is common for both sending and
> > >>
> > > recieving
> > >
> > >> messages.
> > >>
> > >>
> > >>> Having <sp:IncludeTimestamp/> returns "[info] [rampart][shp]
> > >>>
> > > Timestamp
> > >
> > >>> is not in the message", and modifying it to <sp:IncludeTimestamp
> > >>> wsp:Optional="true"/> still comes up with the same error.
> > >>>
> > >> In our current Security policy implementation we are not supporting
> > >> wsp:Optional scenarios yet. Considerable amount of work need to be
> > >>
> > > done
> > >
> > >> to support this.
> > >>
> > >> Is this a frequent scenario?  We haven't encountered this when we
> are
> > >> interoping with other implementations. If it is a common scenario
> then
> > >> we can give a fix just for <sp:IncludeTimestamp> case.
> > >>
> > >>
> > >> Thanks.
> > >> Manjula.
> > >>
> > >>
> > >>
> > >>> Thanks,
> > >>> Jamie
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Manjula Peiris [mailto:[EMAIL PROTECTED]
> > >>>> Sent: 08 August 2007 11:22
> > >>>> To: Apache AXIS C Developers List
> > >>>> Subject: Re: Error: "Key Reference Info is mismatch with policy"?
> > >>>>
> > >>>> Hi Jamie,
> > >>>>
> > >>>> Please check the value of <sp:IncludeToken> attribute in the
> > >>>> <sp:InitiatorToken> element. If it is ,
> > >>>>
> > >>>>
> > >
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always
> > >
> > >>> To
> > >>>
> > >>>> Recipient then the certificate used to signed the message is sent
> > >>>>
> > > only
> > >
> > >>> by
> > >>>
> > >>>> the client to server. The Client should not see it  attached as a
> > >>>> <BinarySecurityToken> in the recieved message. If you want this
> > >>>> <BinarySecurityToken> element to be in the recieved message of
> the
> > >>>>
> > >>> client
> > >>>
> > >>>> please change the <sp:IncludeToken>  attribute to
> > >>>>
> > >>>>
> > >
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always
> > >
> > >>> .
> > >>>
> > >>>> If this does not work please send the policy file you are using.
> > >>>>
> > >>>> Thanks
> > >>>> -Manjula.
> > >>>>
> > >>>>
> > >>>> On Tue, 2007-08-07 at 16:26 +0100, Jamie Lyon wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> I'm writing a client to an existing service in Axis2/C. Can
> > >>>>>
> > > anyone
> > >
> > >>>>> shed any light as to what could cause the above error message
> > >>>>>
> > > "Key
> > >
> > >>>>> Reference Info is mismatch with policy"? It appears to me as
> > >>>>>
> > > though
> > >
> > >>>>> it's saying that the namespace or something in the received
> > >>>>>
> > > message
> > >
> > >>> is
> > >>>
> > >>>>> not matching what is in the policy.xml. You can see the context
> > >>>>>
> > > of
> > >
> > >>> the
> > >>>
> > >>>>> message in the snippet of the debug log below.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> The situation seems odd however, since as you can see from the
> > >>>>>
> > > sent
> > >
> > >>> log,
> > >>>
> > >>>> the message sent by the client is perfectly fine. The namespaces,
> > >>>>
> > >>> tokens
> > >>>
> > >>>> etc... all seem to match that which is received back from the
> > >>>>
> > > server.
> > >
> > >>>>> I have attached the sent and received messages, and below is a
> > >>>>>
> > >>> snippet
> > >>>
> > >>>> of the debug log:
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][shp] Process
> > >>>>>
> > > security
> > >
> > >>>> header
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Security for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> BinarySecurityToken for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Signature for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> SignedInfo for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> CanonicalizationMethod for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> SignatureMethod for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Reference for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Transforms for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Transform for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> DigestMethod for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> DigestValue for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> SignatureValue for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> KeyInfo for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> SecurityTokenReference for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Reference for EncryptedKey
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Security for Signature
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> BinarySecurityToken for Signature
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][axiom] Checking
> > >>>>>
> > > node
> > >
> > >>>> Signature for Signature
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][shp] Processing
> > >>>>>
> > >>> Signature
> > >>>
> > >>>> element.
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [Rampart][shp]Key Reference
> > >>>>>
> > > Info
> > >
> > >>> is
> > >>>
> > >>>> mismatch with policy
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [info]  [rampart][rampart_in_handler]
> > >>>>>
> > >>>> Security Header processing failed.
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [debug] engine.c(292) Axis2 engine
> > >>>>>
> > >>> receive
> > >>>
> > >>>> completed!
> > >>>>
> > >>>>> [Tue Aug  7 16:13:02 2007] [error]
> > >>>>>
> > >>> autogen/axis2_DataService.cpp(1236)
> > >>>
> > >>>> returnNode is NULL: Error code: 2 :: NULL paramater was passed
> > >>>>
> > > when a
> > >
> > >>> non
> > >>>
> > >>>> NULL parameter was expected
> > >>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Jamie
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >
> ---------------------------------------------------------------------
> > >
> > >>>>> 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]
> > >>>>
> > >>>
> > >>>
> > >
> ---------------------------------------------------------------------
> > >
> > >>> 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]
> > >>
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > 
> > 
> > --
> > http://kaushalye.blogspot.com/
> > http://wso2.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]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to