cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: Ideas for 2.2
Date Fri, 20 Jun 2008 15:28:55 GMT
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
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>
>


Mime
View raw message