On Mon, 12 Sep 2011 14:59:37 -0400 Daniel Kulp <[email protected]> wrote:
> On Monday, September 12, 2011 6:01:46 PM Marc Giger wrote: > > Hi Colm et al., > > > > Because it seems it will be just a matter of time until swssf is > > getting into the main repo of the ASF > > Already there: > http://svn.apache.org/repos/asf/webservices/wss4j/branches/swssf/ > Ok, cool. > > > I want to ask you what needs > > to be done to get it into the WSS4J trunk? > > Well, I guess we'd need to create a 1.6.x branch for the ongoing > 1.6.x work. At this point, however, it may make more sense to create > a "temporary" "2.0" branch to get things cleaned up a bit to prepare > it to become the trunk. > > > > > > Colm, you mentioned that swssf could go in the WSS4J 2.0 release. > > Where does the development of WSS4J taking place (trunk?) and is > > there already an ongoing development progress? What are the plans > > for 2.0 and what will be the difference to the current 1.x releases? > > Right now, most of the development that is happening is on trunk > which, right now, is targeting 1.6.x. Obviously, as the development > of 1.6.x winds down and 2.0 winds up, that will need to change. > > > During development of swssf I tried hard to reuse existing projects > > like santuario, neethi, rampart etc. Unfortunately most of the code > > did not fit the requirements that swssf has and I haven't had the > > time to report and discuss possible solutions. This especially true > > for rampart. For some other parts it was probably be doable to > > reuse existing code but since I could do a clean room > > implementation I reimplemented everything which I disliked. This > > does not mean that my implementation is better, I just tried to > > bring in my experience. Particularly by the configuration and > > interface parts. > > > > That said, from my point of view the most important part to work on > > is WS-Policy. Now we have at minimum tree Rampart copies: The > > original Rampart code, CXF customized Rampart and swssf customized > > Rampart. CXF and my implementation/extension of Rampart have a lot > > in common. So if we could bring them back in one core Rampart > > implementation we will have a lot of duplicate code eliminated. To > > begin with, I could refactor the swssf WS-Policy code in an > > maven-submodule. This could help a little to understand and get the > > feeling for the streaming-based policy verification requirements. > > That may make sense. Updating to Neethi 3, removing the Axiom stuff > (would be a requirement for use with CXF), etc... is also a big > step. We'd likely need to look at the CXF policy model and double > check on new things. We've added support for a bunch of extra token > types (like Kerberos and SAML and others) that would likely need to > be pulled back in. We've also added a bunch of validation things > (for post processing) that we'd likely want to make sure work in the > streaming cases as well. (like the XPath expressions and such) > > > > A further point is the configuration. A common configuration for > > WSS4J and swssf would also simplify things. > > > > What are your expectations? What do you dislike and should be > > changed? What are the next steps from your point of view? > > > > In my eyes it would be wrong if we simply adapt swssf to WSS4J and > > other projects so that it just fit. Refactoring and use the best > > concepts of the projects would be the wiser way and could lead to > > really superior major releases. > > +1 to that. :-) > > Couple more things to think about: > 1) Move everything into org.apache.ws.security namespace. One > question to all: should we do "ws.security2" or something so that it > can co-exist with wss4j 1.6.x in process? > > 2) Likewise, move the "generated" code out of the org.oasis and > org.w3. Too many potential conflicts when that is done. Agreed. These classes and its hand made parsing is ugly as hell anyway. I did it this way because I havent't had enough time for a cleaner/better implementation. What I want to try out some time is the following: Writing of a custom JAXB unmarshaller which accepts XMLEvent for XMLEvent. The JAXB-XML-Schema for it would be derived from the official WSS Schemas, whereby these Schemas are limited to that what swssf supports. My expectation of it is a stable XML parsing and validation of the Security-Header. I just have to test how well it performs. What do you think? Does anybody have a better idea? > > 3) Need to work on being able to use XMLStreamReader and > XMLStreamWriter implementations instead of just XMLEvent*. Likely > can wrapper the Stream versions with some sort of Event version, but > I'm not 100% sure if that's possible (haven't completely tried. > There is some utilities in CXF that may help here.). Proper > integration with CXF will definitely need this. Maybe for Axiom as > well (not sure). If you have a look at the org.swssf.interceptor.SecurityInInterceptor org.swssf.interceptor.SecurityOutInterceptor classes you will see that the swssf API already consist of the XMLStream* classes. There is no externaly visible XMLEvent class: SecurityInInterceptor: XMLStreamReader newXmlStreamReader = inboundWSSec.processInMessage(originalXmlStreamReader, requestSecurityEvents, securityEventListener); SecurityOutInterceptor: XMLStreamWriter newXMLStreamWriter = outboundWSSec.processOutMessage(os, encoding, requestSecurityEvents, securityEventListener); These classes are just there to demonstrate how easy it is to integrate swsssf in CXF. ATM the outbound API uses directly an OutputStream but this can with a little bit work be changed so that it writes to an XMLStreamWriter. > > 4) MTOM support - I haven't looked at this yet, but how does it > handle MTOM and other attachment related things? Does it? It doesn't. MTOM is an anti-pattern from swssf's point of view:-) As you already know and as far as I know (others probably do not) WSS requires that an attachment is back inlined before e.g. the signature can be verified. This means, that the whole SOAP-Message must be cached and all advantages of streaming is gone. But it's doable. Marc > > I definitely need to think a bit more and look into the code a bit > more, but those are my initial "top of my head" type thoughts. > > Dan > > > > But this is just my opinion and its ok > > with me whatever the community decides. > > > > Thank you > > > > Kind regrads > > > > Marc > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
