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 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 = "<stderr>") >>> Configure and IDL location for the corba binding: >>> @IDLLocation("file:/foo.idl") >>> Add documentation to the wsdl: >>> @WSDLAnnotation("This operation does XXX") >>> etc... >>> Some of the stuff in the JAX-WS frontend could then be re-written to >>> use that. Processing of the @WebServiceFeature annotations and >>> stuff >>> could be re-implemented that way. The main thing here is to make >>> some of the java-first things work a bit better/easier. (our own >>> @Features annotation could be deprecated in favor of explicit >>> annotations for the features we have) >>> >>> 5) OSGi stuff - I know there are some OSGi enhancements in the works >>> that could be pulled in: >>> a) osgi http transport - this currently lives in ServiceMix, but >>> could be pulled into CXF to work with other OSGi runtimes >>> b) Distributed OSGi (RFC 119) - there is work being done to >>> implement RFC 119 with CXF. There are some rules about releasing >>> the >>> IP for this though that is being investigated. >>> >>> 6) JMS transport enhancements - I keep wanting to update this a bit >>> to >>> leverage spring jms stuff a bit better to make it much easier to >>> configure. >>> >>> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they >>> come up with them. >>> >>> 8) Web site update? I'd like to possibly create a quick logo and >>> update the site a bit to look a bit less like confluence. This is a >>> "would be nice anytime, not just for 2.2" type thing. >>> >>> >>> I'm sure there will be a bunch of other enhancements as well. >>> Stuff >>> like performance/memory enhancements, etc... >>> >>> Anyway, thoughts? Other ideas? Comments? >>> >>> >>> --- >>> Daniel Kulp >>> [EMAIL PROTECTED] >>> http://www.dankulp.com/blog >>> >>> >>> >>> >> >> > > > -- View this message in context: http://www.nabble.com/Ideas-for-2.2-tp17985028p18037357.html Sent from the cxf-dev mailing list archive at Nabble.com.
