Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Date: Thu, 12 Apr 2007 15:02:43 -0400
From: Fred Dushin <fred@dushin.net>
Subject: Re: [PROPOSAL] Unification of coloc and object bindings
In-reply-to: <FA1787F64A095C4090E76EBAF8B183E071FD50@emea-ems1.IONAGLOBAL.com>
To: cxf-dev@incubator.apache.org
Message-id: <0A2AE38D-5DFC-4308-B142-ED30C4B7A35B@dushin.net>
MIME-version: 1.0 (Apple Message framework v752.3)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7bit
References: <FA1787F64A095C4090E76EBAF8B183E071FD50@emea-ems1.IONAGLOBAL.com>

Thank you for this summary, Eoghan.  It really helps to be able to  
sift through the details.

As I have not been in on the whole discussion, I won't speak directly  
to the proposal (though I agree with the principle that for the 80%  
of users who don't understand all of the subtle details of the CXF  
phase architecture, we should keep things as simple and as intuitive  
as possible).

But I do want to raise the spectre of security, and see how this fits  
in the discussion.  This isn't to fall on one side or the other -- I  
just want to know how security will be accommodated in both of these  
scenarios, or at least what the limitations are, vis a vis security,  
with each approach.

Co-location is an important case in security, because if you are  
writing an interceptor that makes access control decisions on the  
basis of information about client identity, asserted or otherwise,  
you always have to do some checking on the credentials representing  
the various identities on the invocation context, before rendering an  
ultimate decision, "yay, you may empty out the account," or "nay,  
you're client IP has been registered with the appropriate authorities."

So at a minimum, as I think we've already talked about here, we need  
to be able to get information from the request context about whether  
an invocation is co-located, or not.

But we may need more information.  For example, if we are making an  
access control decision on the basis of a client identity, then  
presumably we need access to that identity, in whatever form that is  
presented.

The case of a username-password is probably a fairly easy one, since  
it's really just a tuple of security tokens (ostensibly secret, but  
that rule is violated with impunity in most deployments).  Data goes  
in one end, and comes out the other in pretty much the same form it  
went in.  What could be simpler?

But there more complex cases (and arguably more "secure", if there is  
such an adjective) where the identity on the other end of the request  
is not based on simple token propagation, but instead on irrefutable  
evidence, such as a cryptographic signature on a blob or other piece  
of data.  Probably the most common example is SSL (TLS), where the  
security context negotiated over an SSL handshake is established on  
the basis of proof of possession of a private key.  (Leaving aside  
the fact that client certificate authentication is uncommon).

Presumably, in the case of either strategy -- coloc or OB/LT -- SSL  
is out of the picture, as it should be, so let's dutifully sweep SSL  
under the table (for good!).

Unfortunately, there are similar authentication methods at the  
message binding level, whereby a message may be signed by a sender,  
and an access control decision may be rendered on the basis of such a  
signature (or more properly, based on the identity authenticated by  
the signature).  And here it seems the 2 approaches you have outlined  
may start to diverge.

In the coloc case, as I understand your description, the binding is  
circumvented all together, so any opportunity to sign a message is  
lost, as, symmetrically, is any opportunity to verify a signed  
message.  I don't know enough about the OB/LT case -- whether message  
signature and verification is possible in this approach.  If so, then  
that may be a salient difference, at least from a security point of  
view, to the two approaches.

Again, not picking sides here -- just trying to understand the  
differences.  And if the two approaches can live peacefully side-by- 
side, then that's great.  Applications that NEED to do message  
protection in co-located calls will have the opportunity to do so,  
with the right config.  (And trust me, the performance penalty of  
doing asymmetric crypto on XML will so eclipse the gains had by co- 
location, they'll quickly wonder why they went through the bother!)

Also, one other difference between the 2 approaches is that the coloc  
case seems to require that any information represented on a message  
on the outbound side has to be represented in exactly the same way on  
the inbound side.  That is to say (and correct me if I'm wrong), the  
coloc strategy seems to do a little surgery on the interceptor  
chains, such that any information on the Message/Exchange is  
preserved and just forwarded on to the inbound interceptors.

In a limited number of cases, the representation of user "credential"  
information may be isomorphic on the client and server side.  Witness  
our good friend the CXF AuthorizationPolicy.  But I'm not sure that  
we can be guaranteed that this will always be the case -- in some  
cases, low-level interceptors do real work to generate  
representations of user identity (together with any ancillary  
attributes said users may have), and these representations may bear  
no resemblance to the information available on the sending side of an  
invocation.

Again, not a show-stopper for one approach over the other, but worth  
bearing in mind when trying to secure co-located calls.

Hope this hasn't been too much of a ramble.

-Fred

On Apr 12, 2007, at 1:36 PM, Glynn, Eoghan wrote:

>
>
> Folks,
>
> As you may have noticed, Ajay just merged a new co-located binding
> (rt/bindings/coloc), which adaptively provides an optimized dispatch
> path when the target endpoint exists in the local process space.
>
> You may also have noticed DanD's recent commit of an object binding
> (rt/bindings/object) and improved local transport which, while
> originally intended to cover a different use-case, could also be  
> used in
> the co-located scenario.
>
> So I wanted to kick around a few ideas about unifying these two  
> modules
> in such a way that retains the best aspects of both. First let me  
> state
> what I think are the pros and cons of each.
>
> Coloc is the simpler at a conceptual level ... it just detects if the
> protocol and transport layers are unnecessary and if so by-passes  
> these
> completely by weaving a direct interceptor chain from the end of the
> "client-side" logical phase to the start of the "server-side" logical
> phase, and back again. So basically it diverts around the binding and
> port described in the physical contract as realized by the WSDL or
> whatever. This simplicity comes at the cost of a fixed "bridge point",
> i.e. the corresponding logical phases on either side.
>
> The OB/LT approach on the other hand trades some extra complexity for
> flexibility, by potentially also traversing user interceptors in  
> phases
> later than logical on the client-side (or prior to logical on
> server-side). For example, say the user has an interceptor in a stream
> phase, that doesn't actually manipulate streams at all, which they
> specifically want to be included in the optimized form of dispatch.  
> This
> comes at the cost of some extra complexity in terms of the user
> understanding what's going on under the hood. Instead of just  
> completely
> bypassing the unnecessary real binding (e.g. SOAP), this would be
> replaced with a different binding, i.e. the object binding  
> interceptors.
> Similarly the transport layer used in the remote case (e.g. HTTP)  
> would
> be replaced with another, i.e. the local transport. Similarly an
> under-the-hood activation of a LocalDestination would be required when
> the application does an explicit Endpoint.publish("http://...",  
> myImpl)
> or some-such. Of course, there ain't no such thing as a free lunch,  
> and
> this extra complexity is warranted if its really required.
>
> Note that the extra flexibility is absolutely required in the primary
> target use-case for the object binding, i.e. the wider use-case of
> dynamic routing scenarios. My assertion that is that the flexibility
> isn't _necessarily_ required in the narrower coloc use-case.
>
> Personally I can see a lot of merit in both approaches and would  
> like to
> see the best aspects of each retained. The way I'd see this being done
> would be as follows:
>
> 1. The default mode would be to use the coloc approach, in the  
> sense of
> completely bypassing the binding and transport. This will I think suit
> the majority of users and provide a simple conceptual model, i.e.  
> avoid
> questions like "wait a minute, I asserted the Addressing policy on the
> SOAP binding in the WSDL, but this may be replaced by an object  
> binding
> at runtime ... does this mean a different set of binding-level  
> policies
> are used?", or "what's this LocalDestination I see popping up in the
> logs, I didn't order one of those" ... etc.
>
> 2. An advanced option would be to allow the user choose via
> configuration exactly which phases should be run. This would suit
> advanced users who understand the CXF Phase architecture  
> sufficiently to
> deliberately deploy a non-stream-manipulating interceptor into a  
> stream
> phase. So for example they might want to ensure that an interceptor
> responsible for measuring the transport-level latency is run as  
> close to
> the wire as possible, but also ensure that another non-logical
> interceptor that does say compression isn't run at all (as clearly its
> not needed in the colocated case).
>
> The beauty of the above proposal in my view is that the user only  
> incurs
> the cost (in terms of complexity) of using the object binding and  
> local
> transport, when it actually pays off with some flexibility that *they
> want and need*.
>
> Note that in both approaches, the user must consciously enable the
> specialized form of dispatch (by adding an interceptor to the  
> configured
> chain), so this feature is never foisted on them.
>
> Also the detection that the opimitized path is valid would be adaptive
> in both cases. So if the target endpoint pops up the local process
> space, we get to take advantage of a more direct invocation route,
> whereas if it subsequently migrates away to another container, the
> runtime transparently reverts back the normal route (e.g. via SOAP  
> over
> HTTP).
>
> Other differences between coloc & OB that don't depend on the distinct
> approaches taken, such as coloc's more complete fault handling, could
> easily be leveraged in both cases.
>
> Thoughts?
>
> Cheers,
> Eoghan
>