Hi Ruchith,
     I have raised a JIRA for the problem: 
https://issues.apache.org/jira/browse/RAMPART-18

Thanks,
Sriram Vaidyanathan
Software Engineer - Java
Copart Auto Auctions, Inc.
4665 Business Center Drive
Fairfield, CA 94534
www.copart.com <http://www.copart.com/> 
(707) 639-5428

-----Original Message-----
From: Ruchith Fernando [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 8:51 PM
To: axis-user@ws.apache.org
Subject: Re: Configuration in Rampart 1.1

Hi,

We need to do this.
JIRA please :-)

Thanks,
Ruchith

On 1/27/07, Sriram Vaidyanathan <[EMAIL PROTECTED]> wrote:
> Thanks Ruchith.
>  Another question I had is, If I had defined custom fault to be thrown from 
> an operation and those faults are currently not getting secured. Is there a 
> way to secure the outgoing faults from the service with the same security 
> policy used for securing outgoing messages.?
>
> Thanks,
> Sriram Vaidyanathan
> Software Engineer - Java
> Copart Auto Auctions, Inc.
> 4665 Business Center Drive
> Fairfield, CA 94534
> www.copart.com <http://www.copart.com/>
> (707) 639-5428
>
> -----Original Message-----
> From: Ruchith Fernando [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 24, 2007 6:34 PM
> To: axis-user@ws.apache.org
> Subject: Re: Configuration in Rampart 1.1
>
> Hi Sriram,
>
> This should be possible by specifying message level policies in the
> services.xml.
>
> Simply remove the EncryptedParts and SignedParts assertions from the
> service level policy and include those assertions at the message
> level. For example:
>
> <service>
>         <operation name="echo">
>                 <message label="in">
>                      <wsp:Policy wsu:Id="InputMessagePolicy"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
>                         <sp:SignedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>                                 <sp:Body/>
>                         </sp:SignedParts>
>                         <sp:EncryptedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>                                 <sp:Body/>
>                         </sp:EncryptedParts>
>                      </wsp:Policy>
>                 </message>
>         </operation>
>
>         <wsp:Policy wsu:Id="ServicePolicy"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
>                  .........
>                  .........
>                  .........
>                  .........
>         </wsp:Policy>
>
> </service>
>
> Please make sure that you don't have a
> <sp:OnlySignEntireHeadersAndBody/> assertion in the binding policy as
> well.
>
>
> Thanks,
> Ruchith
>
> On 1/25/07, Sriram Vaidyanathan <[EMAIL PROTECTED]> wrote:
> > Hello Ruchith /Dimuthu,
> >
> > Thanks for your responses!!
> >
> > I was just using the Policy sample03, which does both the Signature and the 
> > Encryption, and it works very well. My question is there a way for me to 
> > specify to the service to only expect "Inflow" messages to be secured and 
> > not secure "Outflow" messages like it was possible in the Rampart 1.0 
> > configuration.
> >
> > Thanks,
> > Sriram Vaidyanathan
> > Software Engineer - Java
> > Copart Auto Auctions, Inc.
> > 4665 Business Center Drive
> > Fairfield, CA 94534
> > www.copart.com <http://www.copart.com/>
> > (707) 639-5248
> >
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:[EMAIL PROTECTED]
> > Sent: Friday, January 19, 2007 2:56 AM
> > To: axis-user@ws.apache.org
> > Subject: Re: Configuration in Rampart 1.1
> >
> > Hi Sriram,
> >
> > Note that you must use Rampart policy[1] in configuring rampart along
> > with the standard WS-SecurityPolicy.
> >
> > The WS-SecPolicy stuff are not really straight forward. Therefore I
> > believe we will be maintaining the rampart-1.0 configuration for a few
> > more versions :-). However the rampart-1.0 configuration causes a few
> > issues when we try to interop with other implementations. For example
> > if the endpoint policy requires a signed Timestamp with "strict"
> > header layout, the rampart-1.0 configuration fails to satisfy those
> > requirements. Therefore the best option
> >
> > Thanks,
> > Ruchith
> >
> > [1] 
> > http://ws.apache.org/axis2/modules/rampart/1_1/sec-conf/rampart-config.xsd
> >
> > On 1/18/07, Dimuthu Leelaratne <[EMAIL PROTECTED]> wrote:
> > > Hi Sriram,
> > >
> > > As I understand your single client can tallk to multiple services but
> > > with different security requirements. For configurations now we
> > > encourage using Policy file according to WS Security Policy
> > > specification 
> > > (http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf).
> > >
> > > Since your services require different security settings, we may have
> > > to create different Policy.xml files. After that according to the
> > > service the client is going to invoke you  can load the relevant
> > > Policy file as follows.
> > >
> > >         StAXOMBuilder builder  = new StAXOMBuilder(pathToPolicyfile);
> > >         Policy clientPolicy =
> > > PolicyEngine.getPolicy(builder.getDocumentElement());
> > >         //setting the object
> > >         Options options = new Options();
> > >         options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
> > > clientPolicy);
> > >
> > >
> > > Schemas are available at,
> > > http://ws.apache.org/axis2/modules/rampart/1_1/security-module.html
> > >
> > > Cheers,
> > > Dimuthu
> > >
> > >
> > >
> > > On 1/18/07, Sriram Vaidyanathan <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >      I am currently trying to upgrade to Rampart 1.1 from Rampart 1.0 
> > > > and using Rampart 1.0 we could talk to multiple services from a single 
> > > > client by programmatically configuring the parameters using the 
> > > > OutflowConfiguration class.
> > > >
> > > > From previous posts in the forum it looks like these are deprecated 
> > > > with the 1.1 releases. Is there an alternative way we can dynamically 
> > > > configure the parameters in 1.1?  Any help on this would be appreciated.
> > > >
> > > > Thanks and Regards
> > > > Sriram Vaidyanathan
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > www.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]
> >
> >
>
>
> --
> www.ruchith.org
> www.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]
>
>


--
www.ruchith.org
www.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]

Reply via email to