axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruchith Fernando" <ruchith.ferna...@gmail.com>
Subject Re: Configuration in Rampart 1.1
Date Mon, 05 Feb 2007 11:19:53 GMT
Good question ! IMHO we don't have a way to do this right now... Will
create a JIRA issue to fix it.

Thanks,
Ruchith

On 2/5/07, Sriram Vaidyanathan <Sriram.Vaidyanathan@copart.com> wrote:
> Hi Ruchith,
>   The message label works well for the service side where only the incoming messages
are expected to be secured.
>    Suppose if I want the client to only secure outgoing messages and not expect any security
for incoming messages, is it possible to specify the message label defintion in the client's
policy.xml?
>
> Thanks
> Sriram Vaidyanathan
>
>
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> 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 <Sriram.Vaidyanathan@copart.com> 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:ruchith.fernando@gmail.com]
> > 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 <dimuthu.leelaratne@gmail.com> 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 <Sriram.Vaidyanathan@copart.com> 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: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> > www.wso2.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>


-- 
www.ruchith.org
www.wso2.org

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


Mime
View raw message