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, whileoriginally intended to cover a different use-case, could also be used inthe 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 statewhat I think are the pros and cons of each. Coloc is the simpler at a conceptual level ... it just detects if theprotocol and transport layers are unnecessary and if so by-passes thesecompletely 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 forflexibility, by potentially also traversing user interceptors in phaseslater 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 theyspecifically want to be included in the optimized form of dispatch. Thiscomes at the cost of some extra complexity in terms of the userunderstanding what's going on under the hood. Instead of just completelybypassing the unnecessary real binding (e.g. SOAP), this would bereplaced with a different binding, i.e. the object binding interceptors. Similarly the transport layer used in the remote case (e.g. HTTP) wouldbe replaced with another, i.e. the local transport. Similarly an under-the-hood activation of a LocalDestination would be required whenthe application does an explicit Endpoint.publish("http://...";, myImpl) or some-such. Of course, there ain't no such thing as a free lunch, andthis 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 tosee 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 ofcompletely bypassing the binding and transport. This will I think suitthe majority of users and provide a simple conceptual model, i.e. avoidquestions like "wait a minute, I asserted the Addressing policy on theSOAP binding in the WSDL, but this may be replaced by an object binding at runtime ... does this mean a different set of binding-level policiesare 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 suitadvanced users who understand the CXF Phase architecture sufficiently to deliberately deploy a non-stream-manipulating interceptor into a streamphase. So for example they might want to ensure that an interceptorresponsible for measuring the transport-level latency is run as close tothe 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 localtransport, when it actually pays off with some flexibility that *they want and need*. Note that in both approaches, the user must consciously enable thespecialized form of dispatch (by adding an interceptor to the configuredchain), 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, theruntime transparently reverts back the normal route (e.g. via SOAP overHTTP). 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
