Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon L.,
My comments follow.
Thanks,
Gang
--- cut ---
>
> Trying to catch up....
>
> I think there is a question here of how generic the security code is.
>
> If it's common code that is intended to encrypt messages regardless of
> what binding is used then it needs to be independent of the binding.
> It it does depend on the type of binding then things are different.
> For WS Security support in 1.x we chose to use the Rampart module of
> Axis so our security policies in that area just provide configuration
> to the Rampart module. Hence we allow the guts of Axis to do whatever
> it needs to do and just provide the appropriate configuration.
>
> This case of providing a bespoke policy that has to run in the context
> of a binding is, as we are finding here, tricky because in 1.x we
> started out with an infrastructure model that treated the binding as a
> black box. The policy handlers beforeInvoke/afterInvoke were a first
> attempt to resolve it but we added then in a very binding specific
> way. I.e. where they appear and get called is binding dependent.
Yes, you are right. The "black box" treatment is the root cause of the
problems in 1.6.x ws binding implementation. For security, it needs to
access some intermediate states in that black box and insert logic in
the middle. The four issues I raised and summarized in this thread are
all related to this needs.
>
> We backed away from this approach for the JMS and HTTP bindings in 1.x
> and created the binding chain [1]. We went this route to support
> features, such as wireFormat and operationSelection, that the OASIS
> specifications introduced. What it does is introduce the familiar
> handler infrastructure into the guts of the binding implementation so
> opening up the black box and making it more pluggable. So, for
> example, on the reference side you might find that a binding does the
> following
>
> Set up the binding context -> some arbitrary handlers (policy,
> wireFormat etc) -> transport processing
>
> And on the service side the reverse is true.
>
> transport processing -> some arbitrary handlers (policy, wireFormat
> etc) -> Operation selection
I like the above visual pictures. I remember seeing the list of phases
in the interceptor framework code that would have supported this
pictures. I guess it's just not yet completely implemented.
>
> In 2.x the JMS and HTTP binding came over from 1.x pretty much as is
> and we started converting the ws-axis binding to this pattern. The new
> PolicyProvider interface has extra methods [2] which still support
> policy interceptors being created for the normal operation chain but
> adds the ability to create interceptors for the binding chain and also
> allows the provider the opportunity to configure a binding directly if
> required.
>
> Another thing we started looking at in 2.x was alternative
> implementations of binding.ws. In particular we started looking at
> what it would take to build the binding on top of JAXWS. We have a
> simple JDK/RI based version running but didn't get the Axis/JAXWS
> version running. We redirected our effort to getting the existing
> binding-ws-axis2 binding to being compliant with the OASIS specs. If
> someone were to finish off the JAXWS support then in theory you could
> add JAXWS interceptors directly the ws binding
>
> None of this information is directly helping solve Yang's immediate
> problem but I want to make sure issues raised on this thread are
> resolved in 2.x. I suspect that some of these issues are still
> relevant.
>
> Re. the question of calling afterInvoke() in fault cases. Would there
> be problem with letting the infrastructure continue to do the fault
> processing but give afterInvoke() a chance to process any faults
> created, for example, in Axis2ServiceInOutSyncMessageReceiver ..
>
>
> } catch (InvocationTargetException e) {
> Throwable t = e.getCause();
> if (t instanceof FaultException &&
> ((FaultException)t).getFaultInfo() instanceof OMElement) {
> OMElement faultDetail =
> (OMElement)((FaultException)t).getFaultInfo();
> inMC.setProperty(Constants.FAULT_NAME,
> faultDetail.getQName().getLocalPart());
> AxisFault f = new AxisFault(null, e.getMessage(),
> "faultNode", "faultRole", faultDetail);
> *** throw f;
> }
> if (t instanceof Exception) {
> *** throw AxisFault.makeFault((Exception)t);
> }
> logger.log(Level.SEVERE, e.getMessage(), t);
> *** throw new ServiceRuntimeException(e);
> } catch (Throwable e) {
> logger.log(Level.SEVERE, e.getMessage(), e);
> *** throw AxisFault.makeFault(e);
> }
>
> give afterInvoke the chance to process here ***. A similar thing could
> be done in the invoke() operation of Axis2BindingInvoker. What
> processing are you expecting to do on the fault? If you're intending
> to encrypt the fault response then this isn't going to work on the
> service side as the operation is expecting to throw and exception in
> the fault case.
Simon N. and I were thinking about these places. Unfortunately these
"***" marked places are too early in the fault process for security
processing. I need to access the response SOAP message that contains the
SOAPFault body, which is not available until much later time in the
fault process as I stepped through the code yesterday. But if we can
insert interceptor right before the transport phase in your pictures,
that's doable. The process includes signing and encryption, and
auditing, which does not require SOAP message.
>
>
> [1]
>
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Respons
> e+Binding
> [2] http://svn.apache.org/repos/asf/tuscany/sca-java-
> 2.x/trunk/modules/core-
> spi/src/main/java/org/apache/tuscany/sca/provider/PolicyProvider.java
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Classification: UNCLASSIFIED
Caveats: NONE
