Re: Ideas for 2.2
On Sat, Jun 21, 2008 at 2:35 AM, Glen Mazza <[EMAIL PROTECTED]> wrote: > > >>BTW, Fred, I'm reading "SOA Security" by publisher Manning right now, it > says > >>WSS4J is for Axis 1.x while Rampart is for Axis 2.0. That doesn't seem > >>correct--isn't WSS4J used with both Axis1 and Axis2? Or is it just that > >>Rampart uses WSS4J internally? Yes Rampart is an Axis2 module on top of WSS4J, with a WS-SecurityPolicy implementation, some features to send parts of message by MTOM and some other additional configurations. Thanks Bharath http://thoughts.bharathganesh.com > > > As for the caching of the nonces, don't Axis 1 and Axis2 handle that > themselves (because WSS4J can't do it itself right now, perhaps)? You want > to make sure that if Client X made a request with nonce = 4, no more > requests of X with that nonce value within the timeout period are made, so > that offhand would appear to be something that the web service provider can > handle. Then again, maybe this caching can be handled by WSS4J--less work > for us. > > As for WS-SecureConversation, AFAICT it is just a generalization of > WS-Security[1]--the tokens (of whatever type, Kerberos, SAML, > UsernameToken, > or whatever) are not continually regenerated/resent for each reply/request. > It's primarily a performance issue--WS-SC makes things faster. So I'm not > exactly clear when you write "I think the right way to tackle that is to > integrate with Kerberos and the GSS-API"--I think, whatever you do > WS-SC-wise, would need to be generalized for *all* token profiles, not just > Kerberos. But I'm hardly the most knowledgable on this stuff. > > Regards, > Glen > > [1] http://blogs.sun.com/trustjdg/entry/metro_and_netbeans_for_secure > > > > Fred Dushin-3 wrote: > > > > I think the right place for nonce support is in WSS4J, itself, though > > honestly, a lot of work needs to be done to WSS4J to get it "up to > > snuff" with CXF. (Java5, JaxB support, maven, etc etc) > > > > I'd like to get a sense of what people need, in terms of WS- > > SecureConversation and WS-Trust support. What are the real use-cases > > people need these specs for? Could we talk about specific interop > > scenarios, for example? (WCF and Cardspace are fertile ground) > > > > As far as SAML support in WSS4J, yes, there is some support for this > > profile, but we've run into a few issues: > > > > 1. It's using an outdated version of the opensaml libraries, and the > > opensaml team is reluctant to support the version WSS4J is using; > > 2. WSS4J doesn't provide much more than parsing support (using non- > > standard representation of SAML data types) and signature support. > > There is no support, AFAIK, of the various subject confirmation method > > processing requirements dictated by the WS-Security SAML profile, > > which is really the only guarantee of security (if you care about that > > kind of thing). > > 3. The opensaml folks seem reluctant to use JAX-B types for the > > represenation of SAML Assertions. > > > > WS-SecureConversation is a big topic, and as I've discussed before in > > this forum, I think the right way to tackle that is to integrate with > > Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re- > > inventing the kerberos authentication protocol, and chances are, we'd > > get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or > > even, dare I even say it, ActiveDirectory? (Personally, my feeling is > > that this sort of feature would have the most real value to users, as > > it would give you integrated SSO into your web services, based simply > > on your windows domain -- or PAM -- login. Death to passwords.) > > > > I'd also vote for client-side support for WS-SecurityPolicy. That's a > > big requirement for interop with WCF, for example, and it should help > > to simplify config a lot. > > > > -Fred > > > > On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote: > > > >> I think our WSS4J interceptors really need to support "nonces"--IIRC > >> according to WS-Security w/UsernameToken profile web service calls > >> aren't really secure if those aren't included with the username, > >> password, and timestamp. I am still not sure if WSS4J supports the > >> SAML > >> Token Profile, but that would also something we probably need. Having > >> WS-SecureConversation would not be very meaningful for either SAML or > >> UsernameTokens if we don't have the latter two working yet. (The > >> other > >> profile--X.509--I don't know how well that is supported presently, but > >> if working, WS-SecureConversation then becomes sensible.) > >> > >> Possibly also, an ability to support Sun's XWSS product in addition to > >> WSS4J (although I'm aware of the performance issues you had mentioned > >> earlier), a nice-to-have since Spring-WS apparently supports both. > >> > >> Perhaps also WSDL 2.0? > >> > >> Glen > >> > >> > >> 2008-06-18 Daniel Kulp wrote: > >>> Now that 2.1.1 is being voted on, I'd like to step back a bit an
Re: Ideas for 2.2
BTW, Fred, I'm reading "SOA Security" by publisher Manning right now, it says WSS4J is for Axis 1.x while Rampart is for Axis 2.0. That doesn't seem correct--isn't WSS4J used with both Axis1 and Axis2? Or is it just that Rampart uses WSS4J internally? I'm trying to get a feel for how up-to-date WSS4J is. As for the caching of the nonces, don't Axis 1 and Axis2 handle that themselves (because WSS4J can't do it itself right now, perhaps)? You want to make sure that if Client X made a request with nonce = 4, no more requests of X with that nonce value within the timeout period are made, so that offhand would appear to be something that the web service provider can handle. Then again, maybe this caching can be handled by WSS4J--less work for us. As for WS-SecureConversation, AFAICT it is just a generalization of WS-Security[1]--the tokens (of whatever type, Kerberos, SAML, UsernameToken, or whatever) are not continually regenerated/resent for each reply/request. It's primarily a performance issue--WS-SC makes things faster. So I'm not exactly clear when you write "I think the right way to tackle that is to integrate with Kerberos and the GSS-API"--I think, whatever you do WS-SC-wise, would need to be generalized for *all* token profiles, not just Kerberos. But I'm hardly the most knowledgable on this stuff. Regards, Glen [1] http://blogs.sun.com/trustjdg/entry/metro_and_netbeans_for_secure Fred Dushin-3 wrote: > > I think the right place for nonce support is in WSS4J, itself, though > honestly, a lot of work needs to be done to WSS4J to get it "up to > snuff" with CXF. (Java5, JaxB support, maven, etc etc) > > I'd like to get a sense of what people need, in terms of WS- > SecureConversation and WS-Trust support. What are the real use-cases > people need these specs for? Could we talk about specific interop > scenarios, for example? (WCF and Cardspace are fertile ground) > > As far as SAML support in WSS4J, yes, there is some support for this > profile, but we've run into a few issues: > > 1. It's using an outdated version of the opensaml libraries, and the > opensaml team is reluctant to support the version WSS4J is using; > 2. WSS4J doesn't provide much more than parsing support (using non- > standard representation of SAML data types) and signature support. > There is no support, AFAIK, of the various subject confirmation method > processing requirements dictated by the WS-Security SAML profile, > which is really the only guarantee of security (if you care about that > kind of thing). > 3. The opensaml folks seem reluctant to use JAX-B types for the > represenation of SAML Assertions. > > WS-SecureConversation is a big topic, and as I've discussed before in > this forum, I think the right way to tackle that is to integrate with > Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re- > inventing the kerberos authentication protocol, and chances are, we'd > get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or > even, dare I even say it, ActiveDirectory? (Personally, my feeling is > that this sort of feature would have the most real value to users, as > it would give you integrated SSO into your web services, based simply > on your windows domain -- or PAM -- login. Death to passwords.) > > I'd also vote for client-side support for WS-SecurityPolicy. That's a > big requirement for interop with WCF, for example, and it should help > to simplify config a lot. > > -Fred > > On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote: > >> I think our WSS4J interceptors really need to support "nonces"--IIRC >> according to WS-Security w/UsernameToken profile web service calls >> aren't really secure if those aren't included with the username, >> password, and timestamp. I am still not sure if WSS4J supports the >> SAML >> Token Profile, but that would also something we probably need. Having >> WS-SecureConversation would not be very meaningful for either SAML or >> UsernameTokens if we don't have the latter two working yet. (The >> other >> profile--X.509--I don't know how well that is supported presently, but >> if working, WS-SecureConversation then becomes sensible.) >> >> Possibly also, an ability to support Sun's XWSS product in addition to >> WSS4J (although I'm aware of the performance issues you had mentioned >> earlier), a nice-to-have since Spring-WS apparently supports both. >> >> Perhaps also WSDL 2.0? >> >> Glen >> >> >> 2008-06-18 Daniel Kulp wrote: >>> Now that 2.1.1 is being voted on, I'd like to step back a bit and >>> talk >>> a little about ideas for the next versions. >>> >>> First, most likely, we'll need to do a 2.1.2 release in about 6-8 >>> weeks (and maybe 2.0.8 as well). We've done a very good job of >>> getting fixes out to our users in a timely manner and I'd like to >>> keep >>> that up, but I also would like to think about 2.2 a bit as well. I >>> haven't created the 2.1.x fi
[RESULT] [VOTE] Release CXF 2.0.7
We have 15 +1 votes, 12 are PMC binding. Thus, this vote passes. PMC: dkulp, jgenender, seanoc, ubhole, apaibir, eglynn, bmargulies, ffang, wjiang, gnodet, jgawor, pjones Committer: bganesh, Other: ekanu, gsauthier I'll get the artifacts released. Dan On Jun 17, 2008, at 10:44 AM, Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.7 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.7 release. Over 48 JIRA issues are resolved for 2.0.7 which is a large number of fixes for the 2.0.x branch. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.7 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv Px3oDUHzRTC53LDAs2yxIz8= =fif0 -END PGP SIGNATURE- --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
[RESULT] [VOTE] Release CXF 2.1.1
We have 13 +1 votes, 10 PMC binding: +1 PMC: dkulp, jgenender, seanoc, ubhole, apaibir, eglynn, bmargulies, ffang, wjiang, jgawor +1 Committer: bganesh +1 Other: ekanu, plipka Thus, this vote passes. I'll get the artifacts released. Dan On Jun 17, 2008, at 10:41 AM, Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.1.1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1 release. Over 74 JIRA issues are resolved for 2.1.1 which is a large number of fixes. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.1 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.1 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV80oq8juObtVB0YRAiLyAJ9+HiWq61I9JZ01kRpr4g+L1O7woQCcCHbK G1xxwnA5MSe77DORVGTRy3o= =cx57 -END PGP SIGNATURE- --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: unrecognized parameter -Xdv
Hmm.. I'm not seeing any problems on OSX or Linux.
If I do "rm -rf ~/.m2/repository ; mvn -Pfastinstall", it proceeds to
build everything OK. (although it takes a while to download
everything :-( )
Dan
On Jun 20, 2008, at 10:55 AM, Peter Jones wrote:
Hi there,
When building the cxf-2.1.1 source distribution, or trunk for that
matter,
with a clean local maven repo, from the top level directory, I see
an error
like this when it reaches testutils:
[...]
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
unrecognized parameter -Xdv
Usage: xjc [-options ...] ... [-b
] ...
If dir is specified, all schema files in it will be compiled.
If jar is specified, /META-INF/sun-jaxb.episode binding file will be
compiled.
Options:
[...]
org.apache.tools.ant.ExitException: ExitException: status -1
at
org
.apache
.tools
.ant
.util
.optional.NoExitSecurityManager.checkExit(NoExitSecurityManager.java:
38)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:869)
at com.sun.tools.xjc.Driver._main(Driver.java:126)
at com.sun.tools.xjc.Driver.access$000(Driver.java:74)
at com.sun.tools.xjc.Driver$1.run(Driver.java:96)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] ExitException: status -1
If I build inside the testutils directory, there's no problem. So
it only
happens from the top level directory. Has anyone else seen this?
Using java 1.5.0_12 and I've tried with maven 2.0.7 and 2.0.9.
Cheers,
Peter
--
Peter Jones
IONA Technologies
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Ideas for 2.2
I think the right place for nonce support is in WSS4J, itself, though honestly, a lot of work needs to be done to WSS4J to get it "up to snuff" with CXF. (Java5, JaxB support, maven, etc etc) I'd like to get a sense of what people need, in terms of WS- SecureConversation and WS-Trust support. What are the real use-cases people need these specs for? Could we talk about specific interop scenarios, for example? (WCF and Cardspace are fertile ground) As far as SAML support in WSS4J, yes, there is some support for this profile, but we've run into a few issues: 1. It's using an outdated version of the opensaml libraries, and the opensaml team is reluctant to support the version WSS4J is using; 2. WSS4J doesn't provide much more than parsing support (using non- standard representation of SAML data types) and signature support. There is no support, AFAIK, of the various subject confirmation method processing requirements dictated by the WS-Security SAML profile, which is really the only guarantee of security (if you care about that kind of thing). 3. The opensaml folks seem reluctant to use JAX-B types for the represenation of SAML Assertions. WS-SecureConversation is a big topic, and as I've discussed before in this forum, I think the right way to tackle that is to integrate with Kerberos and the GSS-API. Otherwise, we'd probably find ourselves re- inventing the kerberos authentication protocol, and chances are, we'd get it wrong. Why not tie in to a KDC, be it MIT'a, Heimdal'a, or even, dare I even say it, ActiveDirectory? (Personally, my feeling is that this sort of feature would have the most real value to users, as it would give you integrated SSO into your web services, based simply on your windows domain -- or PAM -- login. Death to passwords.) I'd also vote for client-side support for WS-SecurityPolicy. That's a big requirement for interop with WCF, for example, and it should help to simplify config a lot. -Fred On Jun 18, 2008, at 9:32 PM, Glen Mazza wrote: I think our WSS4J interceptors really need to support "nonces"--IIRC according to WS-Security w/UsernameToken profile web service calls aren't really secure if those aren't included with the username, password, and timestamp. I am still not sure if WSS4J supports the SAML Token Profile, but that would also something we probably need. Having WS-SecureConversation would not be very meaningful for either SAML or UsernameTokens if we don't have the latter two working yet. (The other profile--X.509--I don't know how well that is supported presently, but if working, WS-SecureConversation then becomes sensible.) Possibly also, an ability to support Sun's XWSS product in addition to WSS4J (although I'm aware of the performance issues you had mentioned earlier), a nice-to-have since Spring-WS apparently supports both. Perhaps also WSDL 2.0? Glen 2008-06-18 Daniel Kulp wrote: Now that 2.1.1 is being voted on, I'd like to step back a bit and talk a little about ideas for the next versions. First, most likely, we'll need to do a 2.1.2 release in about 6-8 weeks (and maybe 2.0.8 as well). We've done a very good job of getting fixes out to our users in a timely manner and I'd like to keep that up, but I also would like to think about 2.2 a bit as well. I haven't created the 2.1.x fixes branch yet, but I probably will shortly if we start doing some new stuff toward 2.2. That said, here is my list of stuff that is "missing" and could be considered for 2.2: 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff.Not supporting these is becoming increasingly problematic. Most likely, when I get back from my paternity leave, I'm going to start digging into these a bit. I haven't really read up on these yet (in depth) so any help would be greatly appreciated. 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will actually generate some interfaces for xmlbeans, but the sample clients/ servers are wrong (don't set the jaxb databinding) and I'm not sure if the interfaces even work unless you use a jaxws customization to force everything into bare mode. Cleaning this stuff up could be a 2.1.x "fix" as well. 3) JIBX data binding - This is probably the last major thing not ported from XFire. Not sure the demand on it though. 4) Extension via annotation - Benson and I have chatted about this off and on.Basically, we'd like to add hooks into the ReflectServiceFactoryBean so that registered listeners can get events about when things happen. Like when an interface is mapped to a ServiceInfo, a method is mapped to a OperaionInfo and BingingOperationInfo, etc...The listeners can then examine the Method object or Class object or whatever for any additional things it's interested in at runtime. This would allow for some custom annotations. Examples: Configure some logging: @Logging(in = "in.log", out = "out.log", fault = "") Confi
unrecognized parameter -Xdv
Hi there,
When building the cxf-2.1.1 source distribution, or trunk for that matter,
with a clean local maven repo, from the top level directory, I see an error
like this when it reaches testutils:
[...]
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
unrecognized parameter -Xdv
Usage: xjc [-options ...] ... [-b ] ...
If dir is specified, all schema files in it will be compiled.
If jar is specified, /META-INF/sun-jaxb.episode binding file will be
compiled.
Options:
[...]
org.apache.tools.ant.ExitException: ExitException: status -1
at
org.apache.tools.ant.util.optional.NoExitSecurityManager.checkExit(NoExitSecurityManager.java:38)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:869)
at com.sun.tools.xjc.Driver._main(Driver.java:126)
at com.sun.tools.xjc.Driver.access$000(Driver.java:74)
at com.sun.tools.xjc.Driver$1.run(Driver.java:96)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] ExitException: status -1
If I build inside the testutils directory, there's no problem. So it only
happens from the top level directory. Has anyone else seen this?
Using java 1.5.0_12 and I've tried with maven 2.0.7 and 2.0.9.
Cheers,
Peter
--
Peter Jones
IONA Technologies
E-Mail: mailto:[EMAIL PROTECTED]
Tel: 709-738-3725 x321 | Fax: 709-738-3745
570 Newfoundland Drive, St. John's, NL, Canada A1A 5B1
