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 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. > >
