You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2008/10/06 02:03:57 UTC
WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Hello, having just watched my Buffalo Bills get clobbered, I would next like
to test out the WS-SecurityPolicy configuration that Dan has done. Is it
supported only on the CXF 2.2 branch or both 2.1.x and 2.2? Also, is there
any client-side WSDL configuration or is it just service-side WSDL config?
I would think it is just service-side, because we use normal WSS4J config
files for the client-side (and service-side) key/password info, if I'm not
mistaken.
Thanks,
Glen
--
View this message in context: http://www.nabble.com/WS-SecurityPolicy-in-CXF-2.1.x%2C-or-just-2.2--tp19830360p19830360.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Glen Mazza <gl...@gmail.com>.
BTW, is UsernameToken Profile implemented yet via WS-SecurityPolicy or just
the X.509 TP?
Thanks,
Glen
dkulp wrote:
>
>> I would
>> next like to test out the WS-SecurityPolicy configuration that Dan has
>> done. Is it supported only on the CXF 2.2 branch or both 2.1.x and
>> 2.2?
>
> Just 2.2. It's very "unstable" right now as I kind of move things
> around to get it working. Right now, there is pretty much no error
> handling (it likely will just printStackTrace and continue with
> unpredicatble results), I'll probably refactory the sending into 3 (or
> more) interceptors, and the incoming messages are currently not
> validated against the policies. Basically, there is still much work to
> do, but it's at a state where the basic usecases are working. The MS
> InteropFest usecases are now working (except the UsernameToken stuff,
> and I'm not sure why yet. Seems MS wants those encrypted, even if the
> policy says not to, but I haven't dug into all that yet. Not having a
> windows box is slightly hindering that progress.)
>
--
View this message in context: http://www.nabble.com/WS-SecurityPolicy-in-CXF-2.1.x%2C-or-just-2.2--tp19830360p20711459.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Glen Mazza <gl...@gmail.com>.
Thanks, that was it--needed to add that and the cxf-rt-ws-security dependency
as well. Now different error messages but I'm fighting through them.
Glen
dkulp wrote:
>
>
> Glen,
>
> Is this maven based? Have you added a dependency on the
> cxf-rt-ws-policy
> artifact?
>
> Dan
>
>
> On Monday 03 November 2008 7:01:47 am Glen Mazza wrote:
>> dkulp wrote:
>> > Actually, the CLIENT side stuff is MUCH better tested right now. I've
>> > been using the live MS WCF tests at:
>> > http://mssoapinterop.org/ilab/
>> > as my testcases. For the most part, I just run wsdl2java on the wsdls
>> > and have a simple client that calls on them. For each "test case",
>> the
>> > spring config sets the properties that are needed. For example, I
>> > have:
>> >
>> > Turn on the policy stuff: (this will probably be the default for 2.2
>> if
>> > it all works and doesn't affect performance)
>> > <cxf:bus>
>> > <cxf:features>
>> > <p:policies/>
>> > <cxf:logging/>
>> > </cxf:features>
>> > </cxf:bus>
>> >
>> > ...
>>
>> I'm attempting to do this via the following file, which I'm calling
>> cxf.xml
>> and placing in the classpath of my SOAP client:
>>
>> <beans xmlns="http://www.springframework.org/schema/beans"
>> xmlns:cxf="http://cxf.apache.org/core"
>> xmlns:p="http://cxf.apache.org/policy"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="
>> http://cxf.apache.org/core
>> http://cxf.apache.org/schemas/core.xsd
>> http://cxf.apache.org/policy
>> http://cxf.apache.org/schemas/policy.xsd
>> http://www.springframework.org/schema/beans
>> http://www.springframework.org/schema/beans/spring-beans.xsd">
>>
>> <cxf:bus>
>> <cxf:features>
>> <p:policies/>
>> <cxf:logging/>
>> </cxf:features>
>> </cxf:bus>
>> </beans>
>>
>> But I'm getting this error, and Google searches are not helping me:
>>
>> [INFO] WARNING: Failed to create application context.
>> [INFO]
>> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
>> Configuration problem: Unable to locate Spring NamespaceHandler for XML
>> schema namespace [http://cxf.apache.org/policy]
>> [INFO] Offending resource: class path resource [cxf.xml]
>> [INFO]
>> [INFO] at
>> org.springframework.beans.factory.parsing.FailFastProblemReporter.error(Fai
>>lFastProblemReporter.java:68) [INFO] at
>> org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext
>>.java:85) [INFO] at
>> org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext
>>.java:80)
>>
>> Any idea what I'm doing wrong?
>>
>> Thanks,
>> Glen
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/WS-SecurityPolicy-in-CXF-2.1.x%2C-or-just-2.2--tp19830360p20306916.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Daniel Kulp <dk...@apache.org>.
Glen,
Is this maven based? Have you added a dependency on the cxf-rt-ws-policy
artifact?
Dan
On Monday 03 November 2008 7:01:47 am Glen Mazza wrote:
> dkulp wrote:
> > Actually, the CLIENT side stuff is MUCH better tested right now. I've
> > been using the live MS WCF tests at:
> > http://mssoapinterop.org/ilab/
> > as my testcases. For the most part, I just run wsdl2java on the wsdls
> > and have a simple client that calls on them. For each "test case", the
> > spring config sets the properties that are needed. For example, I
> > have:
> >
> > Turn on the policy stuff: (this will probably be the default for 2.2 if
> > it all works and doesn't affect performance)
> > <cxf:bus>
> > <cxf:features>
> > <p:policies/>
> > <cxf:logging/>
> > </cxf:features>
> > </cxf:bus>
> >
> > ...
>
> I'm attempting to do this via the following file, which I'm calling cxf.xml
> and placing in the classpath of my SOAP client:
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:cxf="http://cxf.apache.org/core"
> xmlns:p="http://cxf.apache.org/policy"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://cxf.apache.org/core
> http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/policy
> http://cxf.apache.org/schemas/policy.xsd
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd">
>
> <cxf:bus>
> <cxf:features>
> <p:policies/>
> <cxf:logging/>
> </cxf:features>
> </cxf:bus>
> </beans>
>
> But I'm getting this error, and Google searches are not helping me:
>
> [INFO] WARNING: Failed to create application context.
> [INFO]
> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
> Configuration problem: Unable to locate Spring NamespaceHandler for XML
> schema namespace [http://cxf.apache.org/policy]
> [INFO] Offending resource: class path resource [cxf.xml]
> [INFO]
> [INFO] at
> org.springframework.beans.factory.parsing.FailFastProblemReporter.error(Fai
>lFastProblemReporter.java:68) [INFO] at
> org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext
>.java:85) [INFO] at
> org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext
>.java:80)
>
> Any idea what I'm doing wrong?
>
> Thanks,
> Glen
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Glen Mazza <gl...@gmail.com>.
dkulp wrote:
>
> Actually, the CLIENT side stuff is MUCH better tested right now. I've
> been using the live MS WCF tests at:
> http://mssoapinterop.org/ilab/
> as my testcases. For the most part, I just run wsdl2java on the wsdls
> and have a simple client that calls on them. For each "test case", the
> spring config sets the properties that are needed. For example, I
> have:
>
> Turn on the policy stuff: (this will probably be the default for 2.2 if
> it all works and doesn't affect performance)
> <cxf:bus>
> <cxf:features>
> <p:policies/>
> <cxf:logging/>
> </cxf:features>
> </cxf:bus>
>
> ...
>
I'm attempting to do this via the following file, which I'm calling cxf.xml
and placing in the classpath of my SOAP client:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:cxf="http://cxf.apache.org/core"
xmlns:p="http://cxf.apache.org/policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/policy
http://cxf.apache.org/schemas/policy.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<cxf:bus>
<cxf:features>
<p:policies/>
<cxf:logging/>
</cxf:features>
</cxf:bus>
</beans>
But I'm getting this error, and Google searches are not helping me:
[INFO] WARNING: Failed to create application context.
[INFO]
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML
schema namespace [http://cxf.apache.org/policy]
[INFO] Offending resource: class path resource [cxf.xml]
[INFO]
[INFO] at
org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
[INFO] at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
[INFO] at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
Any idea what I'm doing wrong?
Thanks,
Glen
--
View this message in context: http://www.nabble.com/WS-SecurityPolicy-in-CXF-2.1.x%2C-or-just-2.2--tp19830360p20301570.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Daniel Kulp <dk...@apache.org>.
Glen,
See:
http://e-docs.bea.com/wls/docs103/webserv_intro/interop.html
Particularly the section entitled:
WS-SecurityPolicy Interoperability Guidelines
"As a result, Microsoft .NET 3.0 encrypts the UsernameToken in the
<sp:SignedSupportingTokens> policy assertion. If you use the
<sp:SignedSupportingTokens> policy assertion without encrypting the
UsernameToken, the WebLogic Server and .NET Web Services will not
interoperate."
Dan
On Monday 13 October 2008 9:52:33 pm Glen Mazza wrote:
> dkulp wrote:
> >> I would
> >> next like to test out the WS-SecurityPolicy configuration that Dan has
> >> done. Is it supported only on the CXF 2.2 branch or both 2.1.x and
> >> 2.2?
> >
> > Just 2.2. It's very "unstable" right now as I kind of move things
> > around to get it working. Right now, there is pretty much no error
> > handling (it likely will just printStackTrace and continue with
> > unpredicatble results), I'll probably refactory the sending into 3 (or
> > more) interceptors, and the incoming messages are currently not
> > validated against the policies. Basically, there is still much work to
> > do, but it's at a state where the basic usecases are working. The MS
> > InteropFest usecases are now working (except the UsernameToken stuff,
> > and I'm not sure why yet. Seems MS wants those encrypted, even if the
> > policy says not to, but I haven't dug into all that yet. Not having a
> > windows box is slightly hindering that progress.)
>
> By MS wanting messages encrypted, I'm unsure if you mean message-level or
> transport-level encryption. Regardless, Jiandong Guo of the Metro team has
> written[1] that Metro requires some type of encryption regardless of what
> the policy says. I suspect it is to help idiot-proof their web service
> stack, i.e., they would rather not support an experienced user who has the
> rare requirement for unencrypted username/password tokens in order to keep
> the system solid for the tons of newbies who might otherwise forget to
> encrypt their SOAP messages.
>
> Glen
>
> [1]
> http://www.nabble.com/Re%3A-How-to-implement-WS-Security-with-UsernameToken
>-on-plain-HTTP-transport-p19445662.html
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Glen Mazza <gl...@gmail.com>.
dkulp wrote:
>
>> I would
>> next like to test out the WS-SecurityPolicy configuration that Dan has
>> done. Is it supported only on the CXF 2.2 branch or both 2.1.x and
>> 2.2?
>
> Just 2.2. It's very "unstable" right now as I kind of move things
> around to get it working. Right now, there is pretty much no error
> handling (it likely will just printStackTrace and continue with
> unpredicatble results), I'll probably refactory the sending into 3 (or
> more) interceptors, and the incoming messages are currently not
> validated against the policies. Basically, there is still much work to
> do, but it's at a state where the basic usecases are working. The MS
> InteropFest usecases are now working (except the UsernameToken stuff,
> and I'm not sure why yet. Seems MS wants those encrypted, even if the
> policy says not to, but I haven't dug into all that yet. Not having a
> windows box is slightly hindering that progress.)
>
By MS wanting messages encrypted, I'm unsure if you mean message-level or
transport-level encryption. Regardless, Jiandong Guo of the Metro team has
written[1] that Metro requires some type of encryption regardless of what
the policy says. I suspect it is to help idiot-proof their web service
stack, i.e., they would rather not support an experienced user who has the
rare requirement for unencrypted username/password tokens in order to keep
the system solid for the tons of newbies who might otherwise forget to
encrypt their SOAP messages.
Glen
[1]
http://www.nabble.com/Re%3A-How-to-implement-WS-Security-with-UsernameToken-on-plain-HTTP-transport-p19445662.html
--
View this message in context: http://www.nabble.com/WS-SecurityPolicy-in-CXF-2.1.x%2C-or-just-2.2--tp19830360p19965860.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 05 October 2008, Glen Mazza wrote:
> Hello, having just watched my Buffalo Bills get clobbered,
The AFC east is definitely proving to be quite interesting this year.
The predicted top two teams now have major injury issues, Favre is
resurecting the Jets, and Dolphins are surprisingly good. While things
don't look good for the Pats without Brady, it still should be a fun
season to watch with everything going on.
> I would
> next like to test out the WS-SecurityPolicy configuration that Dan has
> done. Is it supported only on the CXF 2.2 branch or both 2.1.x and
> 2.2?
Just 2.2. It's very "unstable" right now as I kind of move things
around to get it working. Right now, there is pretty much no error
handling (it likely will just printStackTrace and continue with
unpredicatble results), I'll probably refactory the sending into 3 (or
more) interceptors, and the incoming messages are currently not
validated against the policies. Basically, there is still much work to
do, but it's at a state where the basic usecases are working. The MS
InteropFest usecases are now working (except the UsernameToken stuff,
and I'm not sure why yet. Seems MS wants those encrypted, even if the
policy says not to, but I haven't dug into all that yet. Not having a
windows box is slightly hindering that progress.)
> Also, is there any client-side WSDL configuration or is it just
> service-side WSDL config?
Actually, the CLIENT side stuff is MUCH better tested right now. I've
been using the live MS WCF tests at:
http://mssoapinterop.org/ilab/
as my testcases. For the most part, I just run wsdl2java on the wsdls
and have a simple client that calls on them. For each "test case", the
spring config sets the properties that are needed. For example, I
have:
Turn on the policy stuff: (this will probably be the default for 2.2 if
it all works and doesn't affect performance)
<cxf:bus>
<cxf:features>
<p:policies/>
<cxf:logging/>
</cxf:features>
</cxf:bus>
Configure the client: (wsssec 1.1 testcases, symetric binding, x509
ProtectionToken)
<jaxws:client
name="{http://InteropBaseAddress/interop}A_IPingService"
createdFromAPI="true">
<jaxws:properties>
<entry key="ws-security.callback-handler"
value="interop.client.KeystorePasswordCallback"/>
<entry key="ws-security.encryption.username" value="Bob"/>
<entry key="ws-security.encryption.properties"
value="etc/bob.properties"/>
</jaxws:properties>
</jaxws:client>
Or: (wssec 1.0 testcases, asymetric binding)
<jaxws:client
name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncryptRsa15TripleDes_IPingService"
createdFromAPI="true">
<jaxws:properties>
<entry key="ws-security.username" value="Alice"/>
<entry key="ws-security.callback-handler"
value="demo.hw.client.KeystorePasswordCallback"/>
<entry key="ws-security.signature.properties"
value="alice.properties"/>
<entry key="ws-security.encryption.username" value="Bob"/>
<entry key="ws-security.encryption.properties"
value="bob.properties"/>
</jaxws:properties>
</jaxws:client>
There is a SecurityConstants.java file in the ws/security module that
defines the various constants that the runtime will look for. They can
be configured into the client (or endpoint on the server side) via
spring config like above, but you can also use the JAX-WS request
context. For example:
binding.getRequestContext().put("ws-security.encryption.username",
"Bob");
....
Thus, other than turning on the Policy stuff on the bus, it's quite
usable without any configuration at all.
> I would think it is just service-side,
> because we use normal WSS4J config files for the client-side (and
> service-side) key/password info, if I'm not mistaken.
For the crypto stuff, yea. We use the normal Merlin config files, but
thats for both server and client side. Not quite sure what the best way
to deal with that. Feel free to offer suggestions. :-)
HOWEVER, the runtime for the sending side (not the incoming side yet),
will grab a Crypto object out of the message context if available.
Thus, if you build up a Crypto object somehow else, (feature, other
interceptor, stick in the RequestContext, etc...), it will use it.
Thus, if you have some really good ideas, we can implement it ahead of
the Policy out interceptors.
Dan
>
> Thanks,
> Glen
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog