cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Accessing Connection-based info from the transport
Date Mon, 05 Mar 2007 10:57:43 GMT

+1 in principal on transports making information available to the
interceptor chain (and the implementor code).

Certain CXF transports already do this to some extent, for example the
JMSDestination populates the incoming message with a
JMSMessageHeadersType containing, as the name suggests, an aggregation
of JMS header values. Note that in this case the aggregation type is
JAXB-generated (more on this anon).

HTTP takes a simpler approach to propagating the headers, whereby a
Map<String, String> is populated, keyed by the well-known HTTP header

A few points to note however on the detail of your suggestion:

1. Many, if not most, CXF transports do not have direct access to the
underlying IP address. In fact we can't even assume the transport is

2. Even where the IP address is available, it may be spoofed.

>From #1 & #2 it seems to me that it would be difficult to use the IP
address as the basis of a trust decision. If the IP address is absent,
then presumably we'd have to deny trust. Even if the IP address were
present, how would we know the value reported was trust-worthy? Unless
the IP address is provided by a secure transport, then it would seem to
be sortta useless for anything other than say a logging interceptor, and
the transport could have saved the app the trouble and just logged this
info itself.

3. Given that CXF derives a chunk of its value proposition from its
transparent support for multiple transports, I think we'd be getting
into cutting-off-our-own-legs territory with "this information may not
be accessible ... perhaps motivation for not using the transport all

4. Much as Lisp is beloved of many a programmer, the fact is that CXF is
Java-based, so it behooves to use the native idiom of that language.
Which means defining the aggregators as first-class Java types. Any of
the human-readable commentary you speak of could be provided in a more
natural way as javadoc. In addition, machine-readable annotations in
Java 5 give a much more powerful way of decorating the aggregator
object, rather than requiring that the programmer manually "consult the
docs for the expected behavior".

For example, suppose a transport wants to decorate the IPAddress to
indicate that its not spoofable and hence can be used in a trust
decision. It could decorate the getPeerAddress() method with say a
@Trustworthy annotation, which the consumer code could check for as in
an automated way, rather than expecting the human programmer to manually
go read some non-standard contract description (which is obviously prone
to just not being read, or being read but mis-interpreted).

On the issue of the tediousness of hand-crafting the aggregator types,
with their proliferation of boiler-plate get/set methods, I'd agree that
codegen might be the way to go if there were thousands, or hundreds or
even fifty types involved. But it seems to me there would only be of the
order of 10 at most. But you could still go ahead and describe the types
in XML schema if you really wanted to avoid writing boiler-plate Java
code, and then use JAXB to codegen the Java types. However, given that
you probably need to compose these aggregators from non-primitive types
like and, it would
probably be a lot easier to just write a few Java interfaces directly. 


> -----Original Message-----
> From: Fred Dushin [] 
> Sent: 02 March 2007 17:13
> To:
> Subject: Accessing Connection-based info from the transport
> I'd like to get access to some connection-based information 
> from the transport -- in particular, properties relating to 
> any security context established at the transport (e.g., via 
> an SSL handshake, or via a GSS-Accept) --
> Primarily I'm thinking about the server-side of an 
> invocation, though I suspect there may be client-side 
> requirements, as well, though at present they are not as 
> pressing for me.  (They may be later).
> In any event, I've found that the transport is not populating 
> the Message with any of the information I need, so I'd like 
> to propose what I think should be a simple solution.
> First, I understand the fact that there are potentially many 
> different transport implementations, even perhaps for the 
> same protocols.  So in some cases, this information may not 
> be accessible by the transport, which is unfortunate (and 
> perhaps motivation for not using the transport all together, 
> depending on the business requirements).  So the solution 
> should allow for the possibility that some transports can't 
> provide the needed info, so that consumers of the information 
> can code defensively in these situations (throw an exception, 
> log a warning, whatever).
> I can see how the transport destination implementations are 
> instantiating the Message structures, which in turn get 
> passed to the various interceptors (again, talking about the 
> server-side here).  So I'd like the transports, as the divine 
> creators of Messages, to populate said messages with the 
> contextual information I need.  The question then becomes, 
> what should this information look like, and how should it be 
> keyed on the Message?
> We have several alternatives, which I'd like suggestions on 
> before submitting a patch.
> First, I assume for purely organizational purposes we don't want a
> *huge* collection of tags on the Message.  Not that it 
> matters much (the Message is currently implemented as a 
> HashMap, so adding a lot of data should not have an impact on 
> lookup), but perhaps for purely aestheic reasons, it would be 
> better to aggregate this information in some comprehensible manner.
> Going on that assumption, we have some options.  We could 
> define a type or collection thereof, each of which has a 
> collection of accessors (and mutators, for the benefit of our 
> transports), which define which data is available, where the 
> types stowed on these structs are common, well-known, and 
> guaranteed likely-to-exist types, e.g.,
> class/interface TLSTransportInfo {
>[] getPeerCertificateChain() ...
> }
> I started to do this, but the LISP programmer in me said 
> "there has to be a better way".  (I have an innate repulsion 
> to vacuous code, but I'm old-fashioned that way :)  So I 
> turned to our good friend java.util.Map for inspiration (who 
> needs types when you have a cons!).  Why not define leverage 
> a Map<String, Object>, and define a contract for what the 
> structure of the map needs to be -- what tags are associated 
> which what values, which entries are required, vs which are 
> optional.  Hey, they might even be able to be recursive 
> structures, if that's not too difficult for consumers to 
> manage.  The idea is that the data contract is all documented 
> somewhere, so the producers and consumers of the information 
> just need to consult the docs for the expected behavior.
> This has the advantage that we don't have to hand-write all 
> these structs, which are nothing but a collection of 
> accessors and mutators, results in fewer types, and in 
> general just seems a lot cleaner to me.  (I suppose if we 
> could *codegen* these structs, then that would be an 
> advantage, but I'm not sure if you can codegene structs from 
> schema, where the objects stored on the structs are native 
> Java objects.)
> I realize that the Message type is a lot like this (it 
> implements Map<String, Object>), but the semantics of 
> "Message" are probably not appropriate for this use.  Perhaps 
> this new type could be a base-type  
> for Message, so that it has better visibility/use in CF as a whole.   
> Then a Message would extend this type, which it may also contain.   
> Nothing like confusing our users! :)
> Anyway, do folks see this as a potentially valuable addition 
> to CXF?   
> Either way, I need the information from the transport.  I 
> think it just boils down to how we want that information to 
> be represented.
> Thanks,
> -Fred

View raw message