cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: [PROPOSAL] Unification of coloc and object bindings
Date Thu, 12 Apr 2007 19:51:36 GMT


Thanks for the feedback Fred, some initial responses inline ...
 

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 12 April 2007 20:03
> To: cxf-dev@incubator.apache.org
> Subject: Re: [PROPOSAL] Unification of coloc and object bindings
> 
> 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.


Yep, coloc sets a message property,
"org.apache.cxf.message.Message.COLOCATED", to distinguish a colocated
dispatch. OB/LT would do something similar I'd imagine.

 
> 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?


If the security tokens can be generated and applied to the message in
the logical phase (i.e. generated on the basis of the raw Java objects
and then set in message properties), this model could be supported by
either coloc or OB/LT.

If the other hand the security tokens need to be generated on the basis
of a protocol-specific payload (e.g. a SOAP envelope) and stored in a
protocol-specific slot (e.g. SOAP headers), then you're hosed with
either approach and I think we'd have to fallback to a full binding, but
maybe over the local transport as opposed to a remote-capable transport
like HTTP.

 
> 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!).


Yep, SSL is not applicable in either case.
 

> 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.


I think such approaches, e.g. partial message encryption of SOAP
payloads, may be equally problematic in both approaches, as both
effectively use the raw Java objects as the payload.

 
> In the coloc case, as I understand your description, the 
> binding is circumvented all together, 



Yes, in the coloc approach, the binding is circumvented altogether as
you say. In the OB case, the "real binding" is replaced by an object
binding, that isn't really a binding in the normal sense of something
that maps to a particular payload format (SOAP, XML, tagged, whatever).
Instead, as I understand it, the object binding is more of a
place-holder that stands in for the original binding, but retains the
raw Java objects as the payload representation.


> 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.


As I pointed out above, I don't think there's much difference on that
score.


> 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!)


Agreed, in such cases they might be better off just going thru' the
normal binding, and possibly the full-on transport too (depending on
whether they want to reply on say crypto and/or auth provided by the
transport layer, e.g. basic auth over HTTPS).

 
> 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.


Do you mean that the data binding is the same on both sides (e.g. JAXB
with identical customizations)?

Both approaches have this restriction I think, though I reckon in
practice it will hold in most cases.

Ajay has a TODO in the code to check in the ColocOutInterceptor that the
data binding is indeed identical, and to revert to a normal dispatch if
not.

  
> 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.


Correct, a little surgery on the interceptor chains is a good way of
describing it.

 
> 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.


Nope, all good feedback.

Cheers,
Eoghan

 
> -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
> >
> 
> 

Mime
View raw message