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







Reply via email to