Hi Gang All this is coming down to being able to access the on the wire XML that Axis naturally deals with so that a specific, i.e. non-Rampart based, security solution can be provided. The Tuscany 2.x binding interceptors are more closely integrated with the binding implementation but they aren't currently in a position to take part in the Axis handler chain although they can create Axis handles if required. More comments in-line below.
Simon On Fri, Feb 25, 2011 at 10:32 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, Simon, > > Very good summary. My comments follow. > > Gang > >> -----Original Message----- >> From: Simon Laws [mailto:simonsl...@googlemail.com] >> Sent: Friday, February 25, 2011 12:18 PM >> To: dev@tuscany.apache.org >> Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler > exception >> handling issue - PolicyHandler.afterInvoke() is not called when >> SOAPFault is generated (UNCLASSIFIED) >> >> Let me try that again with formatting and with 2.x comments.... >> >> >> As previously discussed the 2,x binding specific interceptor model >> is different from the 1.x model. Policy processing can intercept the >> message flow in two places >> >> Generically on the operation specific wire >> In a binding specific way on the binding wire >> >> The binding specific processing is free to (re-)configure the binding >> as appropriate. For example it can add Axis handlers. Back to the >> issues. This time with 2.x comments attached. >> >> >> TUSCANY-3822 - Service side afterInvoker should be called with the >> outbound Axis MC >> Gang has correct the call to afterInvoke. Demonstrated in two >> attachments to JIRA. There is some discussion of what the sequence >> of calls should be for different MEPs, for example, >> in-only: beforeInvoke(inMC) / afterInvoke(inMC) >> in-out: beforeInvoke(inMC) / afterInvoke(outMC) >> out-only: beforeInvoke(outMC) >> Gang's summary comment >> ====================== >> 1. PolicyHandler.afterInvoke() needs to be called with the >> outbound MessageContext instead of the inbound MC. >> This is critical for WS-security. I have provided my fixes >> in the JIRA. With some generalization we discussed, >> I think this should be fixable in 1.6.x >> 2.x comments >> =========== >> Binding interceptors have access to the binding context >> which in the reference side is OperationClient which >> holds "out" and "in" MessageContext. On the service >> side it's the "in" MessageContext from which I believe you >> can get the "out" MessageContext. We need to look whether >> this asymmetry is necessary > > In addition to what is accessible, there's also a timing issue, which is > also critical. Take the afterInvoke in 1.6.x as an example. Even though > you may be able to get "out" MessageContext from "in" MessageContext, > it's also critical when afterInvoke is called. Before my changes, > afterInvoke is called at a time where "out" MessageContext has not been > set up correctly. Good point, I'll try and extend the current test to provide some insight into what configuration is available at which point. > > Conceptually, "out" MessageContext is more natural on the return > direction. > >> >> >> TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault >> occurs >> Gang has corrected the call to afterInvoke in a patch attached to the >> JIRA >> Sub categories of this issue >> 1. On the service side, any business exceptions from the >> implementation >> cause afterInvoke() to be skipped. Tuscany creates an AxisFault >> wrapping the business exception, and throws this back to Axis2 >> for it to generate the on-the-wire fault. >> 2. On the service side, any system exceptions from the implementation >> (e.g., ServiceRuntimeException) or from beforeInvoke() cause >> afterInvoke() to be skipped. Tuscany creates an AxisFault by >> calling >> AxisFault.makeFault() and throws this back to Axis2 for it to >> generate the on-the-wire fault. >> 3. On the reference side, any AxisFault (either created by Axis2 or >> created by Tuscany on the service side because of cases 1 or 2) >> causes afterInvoke() to be skipped. >> Gang's summary comment >> ====================== >> 4. PolicyHandler.afterInvoke is not called when Fault is >> generated. So far, I have no workaround on this and would >> like a fix. If I remember the code correctly, a quick fix is >> possible if >> Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() >> can catch the exception, create the Fault body and call >> PolicyHandler.afterInvoke() on the service side. I'm not sure >> how >> the client (requester) side works, but the >> PolicyHandler.afterInvoke() >> is also skipped on the return with the Fault. >> 2.x comments >> =========== >> We're going to have to think through this one. We instigated a >> pattern for the async work that we can potentially exploit. I'll >> add faults to the test. > > The JIRA TUSCANY-3838 is only for the sub category 3 per Simon N.'s > categorization. The other two don't have JIRA's yet. > > In the subsequent discussions, Simon and I had concluded that a fix for > sub categories 1 & 2 are non-trivial because the actual AxisFault > processing that creates the SOAPFault body happens much later on for > afterInvoke to be invoked. But in 2.x, if a separate interceptor can be > inserted on the return path, then this can be solved easily and > naturally. 2.x changes will still be required. To get into the guts of Axis we have to either use a Tuscany interceptor to add an Axis handler. We may be able to do more to move the fault creation code so that the Tuscany binding interceptors can see the data created. Alternatively we may have to change the way the binding is structured, for example, maybe we should look again at adopting the JAXWS based binding. We'll have to experiment. > >> >> TUSCANY-???? - Default dispatching mechanism in Axis depends on >> looking at the wrapper element name >> Gang added @WebMethod to the interfaces to drive the generation >> of SOAPAction which Axis will use to select the service operation >> The alternative is to use MessageContext.setSoapAction() in the >> interceptor that does the encryption >> Gang's summary comment >> ====================== >> 2. SOAP message encryption is not supported because the >> PolicyHandler.beforeInvoke() is called after Axis2 dispatching >> phase, which needs to analize SOAP body in order to determine >> the endpoint method. This can be worked around by defining >> SOAPaction in WSDL or Java interface using @WebMethod. >> However, a future fix is still nice to have. >> 2.x comments >> =========== >> I need to run some experiments on this but it looks like the >> TuscanyDispatcher in 2.x is coded to dispatch off the URL. I don't >> know under what circumstances this is used and whether we >> support other dispatching mechanisms > > I think the take-away from this issue is that we need to be able to > insert security interceptors fairly close to the transport. Ideally, > there's not interceptors/processing that would alter the SOAP message > between the two security interceptors (the one on client side and the > one on the service side). This is because message encryption and > signing. Agreed, and we might have to rely on generating Axis handlers to get close to the transport in the Axis based binding.. This is at least possible in 2,x > >> >> >> TUSCANY-???? - We need to be able to pass context "through" a >> component implementation so, for example, the security context >> established when a service is called is available to references >> of that service. >> (1) service binding.ws -> >> (2) handlers -> >> (3) component implementation -> >> (4) handlers -> >> (6) reference binding.ws >> Lots of discussion see, for example, >> http://www.mail-archive.com/dev@tuscany.apache.org/msg15581.html >> Gang's summary comment >> ====================== >> 3. A state-sharing mechanism is needed to allow sharing states >> among service side interceptors/handlers, component and >> reference side interceptors/handlers. I'm currently using the >> ThreadLocal as a workaround, which I wish to have your blessing >> - for now, it's only used from the service handler to component >> and then to reference handler and I hope you can confirm that >> the same thread is used for processing. However, we all agreed >> that this is not desirable to use ThreadLocal in the service >> framework and a state-sharing mechanism is needed. >> 2.x comments >> =========== >> The problem remains. We need to bring all the ideas together >> into a proposal >> >> >> TUSCANY-???? - Where should interceptors be looking for message >> information. Axis MC, Tuscany Message or both and should >> the interceptor be fixing up the relationship between the two when >> encrypting/decrypting >> 2.x comments >> =========== >> In 2.x he binding chain is binding specific so has the opportunity >> to do whatever it needs to do with both structures. We would > expect >> the writier of one of these interceptors to understand both Axis >> and >> Tuscany internals. > > Ideally, with good abstractions, the Tuscany interceptors don't have to > understand other provider-specific implementations. However, in reality, > this is often hard to achieve, especially for an SCA framework like > Tuscany, which is so extensible to brings various implementations and > protocols together. For WS-security, I need to access SOAP message, > which is available from Axis2's MessageContext or JAX-WS's > MessageContext depending on the underlying provider. But for other > message protocols, one may need to access other provider's message > context. > > I would think the main message context of Tuscany interceptors should be > Tuscany's own. From Tuscany's message context, one should be able to > retrieve ANY underlying implementation's message context. There should > be an API to determine the underlying implementation so interceptors can > take appropriate actions. Just my 2 cents. I agree this is worthy goal and it's interesting you bring up the JAXWS angle. It's worth taking another look at this I think as at least that is somewhat standard and understood rather than being Axis specific. We have a basic JAXWS based binding going but It's not OASIS compliant. Putting all of the thoughts/issues you're raised I think we can come up with a model of what we need access to where in the processing chain. On top of this we can assess what the different approaches brings to the table. > >> >> Gang, you offered to send in you 2.0 policy prototype code a one stage >> in the various conversations. Could you do this bay attaching it to a >> new JIRA? > > Unlike 1.6.x, my 2.0 interceptor prototype was very primitive. I was > stuck early on trying to have Tuscany to recognize the new policy. I > definitely can send you that if you think it can be of help. What may be > more helpful is when I start to put more logic in the interceptor's > invoke(). However, the goal for me is to obtain access to the SOAP > message. > >> >> Regards >> >> Simon >> >> >> -- >> Apache Tuscany committer: tuscany.apache.org >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com > > Classification: UNCLASSIFIED > Caveats: NONE > > > Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
