You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Fred Dushin <fr...@dushin.net> on 2007/03/02 18:12:57 UTC
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 {
java.security.cert.Certificate[] 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
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
That certainly could be done, but is currently outside of the scope
of my requirements. The patch I supplied does, FWIW, provide
(optional) access to the SSLSession, from which the host and port can
be obtained, but I realize that's not the same as a
java.net.InetAddress.
My thoughts along those lines are to request a patch when the feature
is needed. I personally do not need it right now, so I'd prefer to
take an incremental approach, given the pace thus far.
-Fred
On Mar 9, 2007, at 2:54 PM, Polar Humenn wrote:
> I would still supply host/port information in the TLS information,
> but why not just supply the JSSE artifacts? Is this to stay
> independent of JSSE? Why?
>
> Fred Dushin wrote:
>> This is fairly technical, so folks on the list not interested in
>> the nitty-gritty need not pay close attention...
>>
>> So basically, what you're proposing is to extend the (internally
>> defined) ServerEngine interface, to, say, yield a reference to a
>> JettyListenerFactory:
>>
>> public interface ServerEngine {
>> ...
>> JettyListenerFactory getJettyListenerFactory();
>> ...
>> }
>>
>> and then extend the JettyListenerFactory interface to, say,
>> perform the needed operation:
>>
>> public interface JettyListenerFactory {
>> ...
>> TLSSessionInfo getTLSSessionInfo(HttpServletRequest request);
>> ...
>> }
>>
>> The implementation of the SSLJettyListenerFactory will then
>> implement this operation, but of course it will need none of it's
>> state to do the work -- it should properly be a static operation
>> (and PMD should really be instrumented to flag this), for that
>> reason alone, but of course it can't be, since it's part of an
>> interface implementation:
>>
>> class SSLJettyListenerFactory ... {
>> ...
>> public final TLSSessionInfo
>> getTSLSessionInfo(final HttpServletRequest request) {
>> final HttpConnection httpCon = req.getHttpConnection();
>> if (httpCon != null) {
>> final Object connection = httpCon.getConnection();
>> if (connection == null) {
>> return null;
>> }
>> if (connection instanceof SSLSocket) {
>> final SSLSocket socket = (SSLSocket) connection;
>> final SSLSession session = socket.getSession();
>> Certificate[] certs = null;
>> try {
>> certs = session.getPeerCertificates();
>> } catch (final SSLPeerUnverifiedException e) {
>> // peer has not been verified
>> }
>> return new TLSSessionInfo(session.getCipherSuite
>> (), session, certs);
>> }
>> }
>> return null;
>> }
>> }
>>
>> And the code in the Destination then reads:
>>
>> final TLSSessionInfo sessionInfo =
>> engine.getJettyListenerFactory().getTSLSessionInfo(req);
>> if (sessionInfo != null) {
>> inMessage.put(TLSSessionInfo.class, sessionInfo);
>> }
>>
>> Is the only reason to go through all of this just to avoid
>> references to JSSE types in the Destination?
>>
>> The same strategy is not available to the ServletController, BTW,
>> so that will need some JSSE specific code in it. And of course in
>> the http2 code, it looks like the old mortbay httpRequest is now a
>> HttpServletRequest, in which case the common code for accessing
>> the TLSSession should properly be in the base
>> AbstractHTTPDestination type. I realize http2 is in flux right
>> now, but is it not to be the new http implementation, or are we
>> planning on having 2 http transport implementations for the
>> forseeable future?
>>
>> -Fred
>>
>>>
>>> Well the only SSL visibility in the org.cxf.transport.http code is
>>> simply to retrieve the configured SSL{Client|Server}Policy so as
>>> to pass
>>> these on to the org.cxf.transport.https code, which then
>>> interprets and
>>> applies the SSL policies.
>>>
>>> As far as the org.cxf.transport.http code is concerned, the
>>> SSL{Client|Server}Policy types are completely opaque, and the only
>>> reason these are even visible in this code was a side-effect of
>>> how the
>>> http-conf schema was defined (i.e. including references to types
>>> defined
>>> in the security schema).
>>>
>>> So I would like to maintain this separation between the http and
>>> https
>>> code.
>>>
>>> Cheers,
>>> Eoghan
>>>
>>>
>>>> Thanks,
>>>> -Fred
>>>>
>>>> On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
>>>>
>>>>> A new patch has been uploaded. Unfortunately, Jira does
>>>> not seem to
>>>>> allow me to remove the old one.
>>>>>
>>>>> Most of the changes Eoghan suggested have been incorporated. In
>>>>> particular
>>>>>
>>>>> * Scratched the idea of a ContextInfo type, since no one took the
>>>>> bait
>>>>> * Added a TLSessionInfo struct (or the best Java has) to carry
>>>>> TLS
>>>>> Session data
>>>>> to the org.apache.cxf.security.transport namespace (API
>>>>> package)
>>>>> * Supported in the Jetty and servlet http transports (http
>>>> and http2)
>>>>> (We gotta fix that!)
>>>>> * Refactored Message and Exchange interfaces (and Impls) to now
>>>>> extend
>>>>> from a common base type -- not strictly needed, but
>>>>> definitely a
>>>>> tidy cleanup
>>>>> in the API
>>>>>
>>>>> Patch is off rev 516352.
>>>>>
>>>>> If someone could quickly review and install the patch, I'd be much
>>>>> obliged.
>>>>>
>>>>> I have no ontological commitments to the proposed changes --
>>>>> mostly
>>>>> just the idea, so please feel free to morph the proposal to
>>>> the idiom
>>>>> du jour (As long as I can extract the needed information out of
>>>>> the
>>>>> transport!).
>>>>>
>>>>> Thanks!
>>>>> -Fred
>>>>>
>>>>> Here's a listing of the changes, as seen from my snapshot:
>>>>>
>>>>> 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
>>>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>>>> http/JettyHTTPDestination.java
>>>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>>>> servlet/ServletController.java
>>>>> M rt/transports/http2/src/test/java/org/apache/cxf/transport/
>>>>> http/JettyHTTPDestinationTest.java
>>>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>>>> http/JettyHTTPDestination.java
>>>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>>>> servlet/ServletController.java
>>>>> M api/src/main/java/org/apache/cxf/message/Exchange.java
>>>>> M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
>>>>> M api/src/main/java/org/apache/cxf/message/Message.java
>>>>> A api/src/main/java/org/apache/cxf/message/StringMap.java
>>>>> M api/src/main/java/org/apache/cxf/message/MessageImpl.java
>>>>> A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
>>>>> A api/src/main/java/org/apache/cxf/security
>>>>> A api/src/main/java/org/apache/cxf/security/transport
>>>>> A api/src/main/java/org/apache/cxf/security/transport/
>>>>> TLSSessionInfo.java
>>>>
>>>>
>>>
>>
>
>
Re: Accessing Connection-based info from the transport
Posted by Polar Humenn <ph...@iona.com>.
I would still supply host/port information in the TLS information, but
why not just supply the JSSE artifacts? Is this to stay independent of
JSSE? Why?
Fred Dushin wrote:
> This is fairly technical, so folks on the list not interested in the
> nitty-gritty need not pay close attention...
>
> So basically, what you're proposing is to extend the (internally
> defined) ServerEngine interface, to, say, yield a reference to a
> JettyListenerFactory:
>
> public interface ServerEngine {
> ...
> JettyListenerFactory getJettyListenerFactory();
> ...
> }
>
> and then extend the JettyListenerFactory interface to, say, perform
> the needed operation:
>
> public interface JettyListenerFactory {
> ...
> TLSSessionInfo getTLSSessionInfo(HttpServletRequest request);
> ...
> }
>
> The implementation of the SSLJettyListenerFactory will then implement
> this operation, but of course it will need none of it's state to do
> the work -- it should properly be a static operation (and PMD should
> really be instrumented to flag this), for that reason alone, but of
> course it can't be, since it's part of an interface implementation:
>
> class SSLJettyListenerFactory ... {
> ...
> public final TLSSessionInfo
> getTSLSessionInfo(final HttpServletRequest request) {
> final HttpConnection httpCon = req.getHttpConnection();
> if (httpCon != null) {
> final Object connection = httpCon.getConnection();
> if (connection == null) {
> return null;
> }
> if (connection instanceof SSLSocket) {
> final SSLSocket socket = (SSLSocket) connection;
> final SSLSession session = socket.getSession();
> Certificate[] certs = null;
> try {
> certs = session.getPeerCertificates();
> } catch (final SSLPeerUnverifiedException e) {
> // peer has not been verified
> }
> return new TLSSessionInfo(session.getCipherSuite(),
> session, certs);
> }
> }
> return null;
> }
> }
>
> And the code in the Destination then reads:
>
> final TLSSessionInfo sessionInfo =
> engine.getJettyListenerFactory().getTSLSessionInfo(req);
> if (sessionInfo != null) {
> inMessage.put(TLSSessionInfo.class, sessionInfo);
> }
>
> Is the only reason to go through all of this just to avoid references
> to JSSE types in the Destination?
>
> The same strategy is not available to the ServletController, BTW, so
> that will need some JSSE specific code in it. And of course in the
> http2 code, it looks like the old mortbay httpRequest is now a
> HttpServletRequest, in which case the common code for accessing the
> TLSSession should properly be in the base AbstractHTTPDestination
> type. I realize http2 is in flux right now, but is it not to be the
> new http implementation, or are we planning on having 2 http transport
> implementations for the forseeable future?
>
> -Fred
>
>>
>> Well the only SSL visibility in the org.cxf.transport.http code is
>> simply to retrieve the configured SSL{Client|Server}Policy so as to pass
>> these on to the org.cxf.transport.https code, which then interprets and
>> applies the SSL policies.
>>
>> As far as the org.cxf.transport.http code is concerned, the
>> SSL{Client|Server}Policy types are completely opaque, and the only
>> reason these are even visible in this code was a side-effect of how the
>> http-conf schema was defined (i.e. including references to types defined
>> in the security schema).
>>
>> So I would like to maintain this separation between the http and https
>> code.
>>
>> Cheers,
>> Eoghan
>>
>>
>>> Thanks,
>>> -Fred
>>>
>>> On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
>>>
>>>> A new patch has been uploaded. Unfortunately, Jira does
>>> not seem to
>>>> allow me to remove the old one.
>>>>
>>>> Most of the changes Eoghan suggested have been incorporated. In
>>>> particular
>>>>
>>>> * Scratched the idea of a ContextInfo type, since no one took the
>>>> bait
>>>> * Added a TLSessionInfo struct (or the best Java has) to carry TLS
>>>> Session data
>>>> to the org.apache.cxf.security.transport namespace (API package)
>>>> * Supported in the Jetty and servlet http transports (http
>>> and http2)
>>>> (We gotta fix that!)
>>>> * Refactored Message and Exchange interfaces (and Impls) to now
>>>> extend
>>>> from a common base type -- not strictly needed, but definitely a
>>>> tidy cleanup
>>>> in the API
>>>>
>>>> Patch is off rev 516352.
>>>>
>>>> If someone could quickly review and install the patch, I'd be much
>>>> obliged.
>>>>
>>>> I have no ontological commitments to the proposed changes -- mostly
>>>> just the idea, so please feel free to morph the proposal to
>>> the idiom
>>>> du jour (As long as I can extract the needed information out of the
>>>> transport!).
>>>>
>>>> Thanks!
>>>> -Fred
>>>>
>>>> Here's a listing of the changes, as seen from my snapshot:
>>>>
>>>> 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
>>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>>> http/JettyHTTPDestination.java
>>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>>> servlet/ServletController.java
>>>> M rt/transports/http2/src/test/java/org/apache/cxf/transport/
>>>> http/JettyHTTPDestinationTest.java
>>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>>> http/JettyHTTPDestination.java
>>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>>> servlet/ServletController.java
>>>> M api/src/main/java/org/apache/cxf/message/Exchange.java
>>>> M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
>>>> M api/src/main/java/org/apache/cxf/message/Message.java
>>>> A api/src/main/java/org/apache/cxf/message/StringMap.java
>>>> M api/src/main/java/org/apache/cxf/message/MessageImpl.java
>>>> A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
>>>> A api/src/main/java/org/apache/cxf/security
>>>> A api/src/main/java/org/apache/cxf/security/transport
>>>> A api/src/main/java/org/apache/cxf/security/transport/
>>>> TLSSessionInfo.java
>>>
>>>
>>
>
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
On Mar 12, 2007, at 9:55 AM, Glynn, Eoghan wrote:
> So I've taken the liberty of modifying your latest patch, to move all
> the various flavours of getTLSSessionInfo() logic to static methods on
> the org.apache.cxf.transport.https.SSLUtils class. The Destination
> impls
> then all just need a single call out to a new
> SSLUtils.propogateSecureSession() method.
Perfect -- I should have just done something like that, too, if
containment was the objective. Sorry for forcing you to do this.
>
> I'm going to go ahead with the commit, but I did notice that you
> updated
> the JettyHTTPDestinationTest in http2 but not http. Was this
> deliberate,
> i.e. have you further test additions in the pipeline?
I don't have anything in the pipeline, no, but I could, if you think
it would be a good idea. The problem I was having was that the http
test is not using EasyMock to create a mock http request -- it's
creating an instance of an org.mortbak.http.HttpRequest, and using
that instance for testing. There is an oblique reference in a
comment in the test to a limitation in EasyMock, such that it was
unable to handle creation of an HttpRequest, but I didn't have time
to track down the real limitation.
The http2 test, on the other hand, seems to have no such difficulty,
presumably because something has changed in the Jetty interfaces, or
the test implementor figured out how to drive EasyMock, or both.
(Good that my changes actually caused the http2 tests to fail, which
forced me into the test code) That was part of the reason I asked
about the half-life of the http module -- if it's living on marked
time, it may not be worth the effort to fix its tests.
> BTW you're preaching to the converted on the issue of the duplication
> across http and http2.
Oh I know that :) I've read your posts on this forum.
> In any case, we do have a long-term plan to sort this out: drop
> support
> for Jetty5, move http2 to http, start taking advantage of the
> non-blocking APIs in Jetty6, and consolidate the duplication across
> the
> Jetty- and servlet-based Destinations.
I guess if we could do this sooner rather than later, then we'd all
benefit. Hard to justify, I understand, when weighed against
tangible featuredom, but more important, IMO, if not making the fix
increases drag on productivity.
-Fred
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Well, my point was that we maintain the existing separation between the
org.apache.cxf.transport.http and org.apache.cxf.transport.https
packages.
Moving getTLSSessionInfo() to the JettySslListenerFactory was just a
suggestion as to how to achieve this.
But if that's problematic, then lets figure out a different means to the
same end.
Also there's little point in just maintaining the separation for the
Jetty5 code, but not the Jetty6 or servlet code.
So I've taken the liberty of modifying your latest patch, to move all
the various flavours of getTLSSessionInfo() logic to static methods on
the org.apache.cxf.transport.https.SSLUtils class. The Destination impls
then all just need a single call out to a new
SSLUtils.propogateSecureSession() method.
I'm going to go ahead with the commit, but I did notice that you updated
the JettyHTTPDestinationTest in http2 but not http. Was this deliberate,
i.e. have you further test additions in the pipeline?
BTW you're preaching to the converted on the issue of the duplication
across http and http2. I've been moaning on this list about the obvious
maintenance issues since this was first committed, and I've suggested
several times that it be removed from the mainline to a branch. I just
noticed that this issue has been made even worse recently, when the
servlet transport was decoupled from the JAX-WS module (a good thing in
itself), but then duplicated to both http and http2 ... Arghhh!
In any case, we do have a long-term plan to sort this out: drop support
for Jetty5, move http2 to http, start taking advantage of the
non-blocking APIs in Jetty6, and consolidate the duplication across the
Jetty- and servlet-based Destinations.
Cheers,
Eoghan
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 09 March 2007 16:51
> To: cxf-dev@incubator.apache.org
> Subject: Re: Accessing Connection-based info from the transport
>
> This is fairly technical, so folks on the list not interested
> in the nitty-gritty need not pay close attention...
>
> So basically, what you're proposing is to extend the (internally
> defined) ServerEngine interface, to, say, yield a reference to a
> JettyListenerFactory:
>
> public interface ServerEngine {
> ...
> JettyListenerFactory getJettyListenerFactory();
> ...
> }
>
> and then extend the JettyListenerFactory interface to, say,
> perform the needed operation:
>
> public interface JettyListenerFactory {
> ...
> TLSSessionInfo getTLSSessionInfo(HttpServletRequest request);
> ...
> }
>
> The implementation of the SSLJettyListenerFactory will then
> implement this operation, but of course it will need none of
> it's state to do the work -- it should properly be a static
> operation (and PMD should really be instrumented to flag
> this), for that reason alone, but of course it can't be,
> since it's part of an interface implementation:
>
> class SSLJettyListenerFactory ... {
> ...
> public final TLSSessionInfo
> getTSLSessionInfo(final HttpServletRequest request) {
> final HttpConnection httpCon = req.getHttpConnection();
> if (httpCon != null) {
> final Object connection = httpCon.getConnection();
> if (connection == null) {
> return null;
> }
> if (connection instanceof SSLSocket) {
> final SSLSocket socket = (SSLSocket) connection;
> final SSLSession session = socket.getSession();
> Certificate[] certs = null;
> try {
> certs = session.getPeerCertificates();
> } catch (final SSLPeerUnverifiedException e) {
> // peer has not been verified
> }
> return new TLSSessionInfo(session.getCipherSuite(),
> session, certs);
> }
> }
> return null;
> }
> }
>
> And the code in the Destination then reads:
>
> final TLSSessionInfo sessionInfo =
> engine.getJettyListenerFactory().getTSLSessionInfo(req);
> if (sessionInfo != null) {
> inMessage.put(TLSSessionInfo.class, sessionInfo);
> }
>
> Is the only reason to go through all of this just to avoid
> references to JSSE types in the Destination?
>
> The same strategy is not available to the ServletController,
> BTW, so that will need some JSSE specific code in it. And of
> course in the
> http2 code, it looks like the old mortbay httpRequest is now
> a HttpServletRequest, in which case the common code for
> accessing the TLSSession should properly be in the base
> AbstractHTTPDestination type. I realize http2 is in flux
> right now, but is it not to be the new http implementation,
> or are we planning on having 2 http transport implementations
> for the forseeable future?
>
> -Fred
>
> >
> > Well the only SSL visibility in the org.cxf.transport.http code is
> > simply to retrieve the configured SSL{Client|Server}Policy so as to
> > pass these on to the org.cxf.transport.https code, which then
> > interprets and applies the SSL policies.
> >
> > As far as the org.cxf.transport.http code is concerned, the
> > SSL{Client|Server}Policy types are completely opaque, and the only
> > reason these are even visible in this code was a side-effect of how
> > the http-conf schema was defined (i.e. including references
> to types
> > defined in the security schema).
> >
> > So I would like to maintain this separation between the
> http and https
> > code.
> >
> > Cheers,
> > Eoghan
> >
> >
> >> Thanks,
> >> -Fred
> >>
> >> On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
> >>
> >>> A new patch has been uploaded. Unfortunately, Jira does
> >> not seem to
> >>> allow me to remove the old one.
> >>>
> >>> Most of the changes Eoghan suggested have been incorporated. In
> >>> particular
> >>>
> >>> * Scratched the idea of a ContextInfo type, since no one
> took the
> >>> bait
> >>> * Added a TLSessionInfo struct (or the best Java has) to
> carry TLS
> >>> Session data
> >>> to the org.apache.cxf.security.transport namespace
> (API package)
> >>> * Supported in the Jetty and servlet http transports (http
> >> and http2)
> >>> (We gotta fix that!)
> >>> * Refactored Message and Exchange interfaces (and Impls) to now
> >>> extend
> >>> from a common base type -- not strictly needed, but
> definitely a
> >>> tidy cleanup
> >>> in the API
> >>>
> >>> Patch is off rev 516352.
> >>>
> >>> If someone could quickly review and install the patch,
> I'd be much
> >>> obliged.
> >>>
> >>> I have no ontological commitments to the proposed changes
> -- mostly
> >>> just the idea, so please feel free to morph the proposal to
> >> the idiom
> >>> du jour (As long as I can extract the needed information
> out of the
> >>> transport!).
> >>>
> >>> Thanks!
> >>> -Fred
> >>>
> >>> Here's a listing of the changes, as seen from my snapshot:
> >>>
> >>> 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
> >>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
> >>> http/JettyHTTPDestination.java
> >>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
> >>> servlet/ServletController.java
> >>> M rt/transports/http2/src/test/java/org/apache/cxf/transport/
> >>> http/JettyHTTPDestinationTest.java
> >>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> >>> http/JettyHTTPDestination.java
> >>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> >>> servlet/ServletController.java
> >>> M api/src/main/java/org/apache/cxf/message/Exchange.java
> >>> M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
> >>> M api/src/main/java/org/apache/cxf/message/Message.java
> >>> A api/src/main/java/org/apache/cxf/message/StringMap.java
> >>> M api/src/main/java/org/apache/cxf/message/MessageImpl.java
> >>> A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
> >>> A api/src/main/java/org/apache/cxf/security
> >>> A api/src/main/java/org/apache/cxf/security/transport
> >>> A api/src/main/java/org/apache/cxf/security/transport/
> >>> TLSSessionInfo.java
> >>
> >>
> >
>
>
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
This is fairly technical, so folks on the list not interested in the
nitty-gritty need not pay close attention...
So basically, what you're proposing is to extend the (internally
defined) ServerEngine interface, to, say, yield a reference to a
JettyListenerFactory:
public interface ServerEngine {
...
JettyListenerFactory getJettyListenerFactory();
...
}
and then extend the JettyListenerFactory interface to, say, perform
the needed operation:
public interface JettyListenerFactory {
...
TLSSessionInfo getTLSSessionInfo(HttpServletRequest request);
...
}
The implementation of the SSLJettyListenerFactory will then implement
this operation, but of course it will need none of it's state to do
the work -- it should properly be a static operation (and PMD should
really be instrumented to flag this), for that reason alone, but of
course it can't be, since it's part of an interface implementation:
class SSLJettyListenerFactory ... {
...
public final TLSSessionInfo
getTSLSessionInfo(final HttpServletRequest request) {
final HttpConnection httpCon = req.getHttpConnection();
if (httpCon != null) {
final Object connection = httpCon.getConnection();
if (connection == null) {
return null;
}
if (connection instanceof SSLSocket) {
final SSLSocket socket = (SSLSocket) connection;
final SSLSession session = socket.getSession();
Certificate[] certs = null;
try {
certs = session.getPeerCertificates();
} catch (final SSLPeerUnverifiedException e) {
// peer has not been verified
}
return new TLSSessionInfo(session.getCipherSuite(),
session, certs);
}
}
return null;
}
}
And the code in the Destination then reads:
final TLSSessionInfo sessionInfo =
engine.getJettyListenerFactory().getTSLSessionInfo(req);
if (sessionInfo != null) {
inMessage.put(TLSSessionInfo.class, sessionInfo);
}
Is the only reason to go through all of this just to avoid references
to JSSE types in the Destination?
The same strategy is not available to the ServletController, BTW, so
that will need some JSSE specific code in it. And of course in the
http2 code, it looks like the old mortbay httpRequest is now a
HttpServletRequest, in which case the common code for accessing the
TLSSession should properly be in the base AbstractHTTPDestination
type. I realize http2 is in flux right now, but is it not to be the
new http implementation, or are we planning on having 2 http
transport implementations for the forseeable future?
-Fred
>
> Well the only SSL visibility in the org.cxf.transport.http code is
> simply to retrieve the configured SSL{Client|Server}Policy so as to
> pass
> these on to the org.cxf.transport.https code, which then interprets
> and
> applies the SSL policies.
>
> As far as the org.cxf.transport.http code is concerned, the
> SSL{Client|Server}Policy types are completely opaque, and the only
> reason these are even visible in this code was a side-effect of how
> the
> http-conf schema was defined (i.e. including references to types
> defined
> in the security schema).
>
> So I would like to maintain this separation between the http and https
> code.
>
> Cheers,
> Eoghan
>
>
>> Thanks,
>> -Fred
>>
>> On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
>>
>>> A new patch has been uploaded. Unfortunately, Jira does
>> not seem to
>>> allow me to remove the old one.
>>>
>>> Most of the changes Eoghan suggested have been incorporated. In
>>> particular
>>>
>>> * Scratched the idea of a ContextInfo type, since no one took the
>>> bait
>>> * Added a TLSessionInfo struct (or the best Java has) to carry TLS
>>> Session data
>>> to the org.apache.cxf.security.transport namespace (API package)
>>> * Supported in the Jetty and servlet http transports (http
>> and http2)
>>> (We gotta fix that!)
>>> * Refactored Message and Exchange interfaces (and Impls) to now
>>> extend
>>> from a common base type -- not strictly needed, but definitely a
>>> tidy cleanup
>>> in the API
>>>
>>> Patch is off rev 516352.
>>>
>>> If someone could quickly review and install the patch, I'd be much
>>> obliged.
>>>
>>> I have no ontological commitments to the proposed changes -- mostly
>>> just the idea, so please feel free to morph the proposal to
>> the idiom
>>> du jour (As long as I can extract the needed information out of the
>>> transport!).
>>>
>>> Thanks!
>>> -Fred
>>>
>>> Here's a listing of the changes, as seen from my snapshot:
>>>
>>> 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>> http/JettyHTTPDestination.java
>>> M rt/transports/http/src/main/java/org/apache/cxf/transport/
>>> servlet/ServletController.java
>>> M rt/transports/http2/src/test/java/org/apache/cxf/transport/
>>> http/JettyHTTPDestinationTest.java
>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>> http/JettyHTTPDestination.java
>>> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
>>> servlet/ServletController.java
>>> M api/src/main/java/org/apache/cxf/message/Exchange.java
>>> M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
>>> M api/src/main/java/org/apache/cxf/message/Message.java
>>> A api/src/main/java/org/apache/cxf/message/StringMap.java
>>> M api/src/main/java/org/apache/cxf/message/MessageImpl.java
>>> A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
>>> A api/src/main/java/org/apache/cxf/security
>>> A api/src/main/java/org/apache/cxf/security/transport
>>> A api/src/main/java/org/apache/cxf/security/transport/
>>> TLSSessionInfo.java
>>
>>
>
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 09 March 2007 10:46
> To: cxf-dev@incubator.apache.org
> Subject: Re: Accessing Connection-based info from the transport
>
> One other thing -- I did not "refactor" the callout to the
> JettySSLListenerFactory to do this work, because there in no
> information in the SSL code that is needed to retrieve this
> information. It would make sense to have the lookup of the
> TLS Session information in the https namespace, but doing so
> introduces an artifical separation that's not really needed.
> Besides, there are already SSL abstractions in the http
> namespace, so the proposed change introduces no fundamental
> differences in behavior.
Well the only SSL visibility in the org.cxf.transport.http code is
simply to retrieve the configured SSL{Client|Server}Policy so as to pass
these on to the org.cxf.transport.https code, which then interprets and
applies the SSL policies.
As far as the org.cxf.transport.http code is concerned, the
SSL{Client|Server}Policy types are completely opaque, and the only
reason these are even visible in this code was a side-effect of how the
http-conf schema was defined (i.e. including references to types defined
in the security schema).
So I would like to maintain this separation between the http and https
code.
Cheers,
Eoghan
> Thanks,
> -Fred
>
> On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
>
> > A new patch has been uploaded. Unfortunately, Jira does
> not seem to
> > allow me to remove the old one.
> >
> > Most of the changes Eoghan suggested have been incorporated. In
> > particular
> >
> > * Scratched the idea of a ContextInfo type, since no one took the
> > bait
> > * Added a TLSessionInfo struct (or the best Java has) to carry TLS
> > Session data
> > to the org.apache.cxf.security.transport namespace (API package)
> > * Supported in the Jetty and servlet http transports (http
> and http2)
> > (We gotta fix that!)
> > * Refactored Message and Exchange interfaces (and Impls) to now
> > extend
> > from a common base type -- not strictly needed, but definitely a
> > tidy cleanup
> > in the API
> >
> > Patch is off rev 516352.
> >
> > If someone could quickly review and install the patch, I'd be much
> > obliged.
> >
> > I have no ontological commitments to the proposed changes -- mostly
> > just the idea, so please feel free to morph the proposal to
> the idiom
> > du jour (As long as I can extract the needed information out of the
> > transport!).
> >
> > Thanks!
> > -Fred
> >
> > Here's a listing of the changes, as seen from my snapshot:
> >
> > 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
> > M rt/transports/http/src/main/java/org/apache/cxf/transport/
> > http/JettyHTTPDestination.java
> > M rt/transports/http/src/main/java/org/apache/cxf/transport/
> > servlet/ServletController.java
> > M rt/transports/http2/src/test/java/org/apache/cxf/transport/
> > http/JettyHTTPDestinationTest.java
> > M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> > http/JettyHTTPDestination.java
> > M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> > servlet/ServletController.java
> > M api/src/main/java/org/apache/cxf/message/Exchange.java
> > M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
> > M api/src/main/java/org/apache/cxf/message/Message.java
> > A api/src/main/java/org/apache/cxf/message/StringMap.java
> > M api/src/main/java/org/apache/cxf/message/MessageImpl.java
> > A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
> > A api/src/main/java/org/apache/cxf/security
> > A api/src/main/java/org/apache/cxf/security/transport
> > A api/src/main/java/org/apache/cxf/security/transport/
> > TLSSessionInfo.java
>
>
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
One other thing -- I did not "refactor" the callout to the
JettySSLListenerFactory to do this work, because there in no
information in the SSL code that is needed to retrieve this
information. It would make sense to have the lookup of the TLS
Session information in the https namespace, but doing so introduces
an artifical separation that's not really needed. Besides, there are
already SSL abstractions in the http namespace, so the proposed
change introduces no fundamental differences in behavior.
Thanks,
-Fred
On Mar 9, 2007, at 5:37 AM, Fred Dushin wrote:
> A new patch has been uploaded. Unfortunately, Jira does not seem
> to allow me to remove the old one.
>
> Most of the changes Eoghan suggested have been incorporated. In
> particular
>
> * Scratched the idea of a ContextInfo type, since no one took the
> bait
> * Added a TLSessionInfo struct (or the best Java has) to carry TLS
> Session data
> to the org.apache.cxf.security.transport namespace (API package)
> * Supported in the Jetty and servlet http transports (http and http2)
> (We gotta fix that!)
> * Refactored Message and Exchange interfaces (and Impls) to now
> extend
> from a common base type -- not strictly needed, but definitely a
> tidy cleanup
> in the API
>
> Patch is off rev 516352.
>
> If someone could quickly review and install the patch, I'd be much
> obliged.
>
> I have no ontological commitments to the proposed changes -- mostly
> just the idea, so please feel free to morph the proposal to the
> idiom du jour (As long as I can extract the needed information out
> of the transport!).
>
> Thanks!
> -Fred
>
> Here's a listing of the changes, as seen from my snapshot:
>
> 05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
> M rt/transports/http/src/main/java/org/apache/cxf/transport/
> http/JettyHTTPDestination.java
> M rt/transports/http/src/main/java/org/apache/cxf/transport/
> servlet/ServletController.java
> M rt/transports/http2/src/test/java/org/apache/cxf/transport/
> http/JettyHTTPDestinationTest.java
> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> http/JettyHTTPDestination.java
> M rt/transports/http2/src/main/java/org/apache/cxf/transport/
> servlet/ServletController.java
> M api/src/main/java/org/apache/cxf/message/Exchange.java
> M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
> M api/src/main/java/org/apache/cxf/message/Message.java
> A api/src/main/java/org/apache/cxf/message/StringMap.java
> M api/src/main/java/org/apache/cxf/message/MessageImpl.java
> A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
> A api/src/main/java/org/apache/cxf/security
> A api/src/main/java/org/apache/cxf/security/transport
> A api/src/main/java/org/apache/cxf/security/transport/
> TLSSessionInfo.java
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
A new patch has been uploaded. Unfortunately, Jira does not seem to
allow me to remove the old one.
Most of the changes Eoghan suggested have been incorporated. In
particular
* Scratched the idea of a ContextInfo type, since no one took the bait
* Added a TLSessionInfo struct (or the best Java has) to carry TLS
Session data
to the org.apache.cxf.security.transport namespace (API package)
* Supported in the Jetty and servlet http transports (http and http2)
(We gotta fix that!)
* Refactored Message and Exchange interfaces (and Impls) to now extend
from a common base type -- not strictly needed, but definitely a
tidy cleanup
in the API
Patch is off rev 516352.
If someone could quickly review and install the patch, I'd be much
obliged.
I have no ontological commitments to the proposed changes -- mostly
just the idea, so please feel free to morph the proposal to the idiom
du jour (As long as I can extract the needed information out of the
transport!).
Thanks!
-Fred
Here's a listing of the changes, as seen from my snapshot:
05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
M rt/transports/http/src/main/java/org/apache/cxf/transport/http/
JettyHTTPDestination.java
M rt/transports/http/src/main/java/org/apache/cxf/transport/
servlet/ServletController.java
M rt/transports/http2/src/test/java/org/apache/cxf/transport/
http/JettyHTTPDestinationTest.java
M rt/transports/http2/src/main/java/org/apache/cxf/transport/
http/JettyHTTPDestination.java
M rt/transports/http2/src/main/java/org/apache/cxf/transport/
servlet/ServletController.java
M api/src/main/java/org/apache/cxf/message/Exchange.java
M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
M api/src/main/java/org/apache/cxf/message/Message.java
A api/src/main/java/org/apache/cxf/message/StringMap.java
M api/src/main/java/org/apache/cxf/message/MessageImpl.java
A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
A api/src/main/java/org/apache/cxf/security
A api/src/main/java/org/apache/cxf/security/transport
A api/src/main/java/org/apache/cxf/security/transport/
TLSSessionInfo.java
On Mar 6, 2007, at 7:04 AM, Glynn, Eoghan wrote:
>
>
>> Similarly for the servlet transport, though instead of a
>> straight copy, in this case you'd be using a different
>> mechanism for retrieving the cipher suite and peer cert (e.g.
>> for Tomcat, probably the
>> org.apache.tomcat.util.net.SSLSupport mechanism, dunno about
>> other containers).
>
> Actually scratch that point about the tomcat SSLSupport API.
>
> Obviously we'd want to keep the servlet transport agnostic to the
> underlying servlet container, so instead you'd be looking at
> pulling out
> this info from the ServletRequest using the standard attributes ...
>
> String ciphers = (String)req.getAttribute
> ("javax.net.ssl.cipher_suite");
> X509Certificate certs[] =
> (X509Certificate[])req.getAttribute
> ("javax.net.ssl.peer_certificates");
>
> Cheers,
> Eoghan
>
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> Similarly for the servlet transport, though instead of a
> straight copy, in this case you'd be using a different
> mechanism for retrieving the cipher suite and peer cert (e.g.
> for Tomcat, probably the
> org.apache.tomcat.util.net.SSLSupport mechanism, dunno about
> other containers).
Actually scratch that point about the tomcat SSLSupport API.
Obviously we'd want to keep the servlet transport agnostic to the
underlying servlet container, so instead you'd be looking at pulling out
this info from the ServletRequest using the standard attributes ...
String ciphers = (String)req.getAttribute("javax.net.ssl.cipher_suite");
X509Certificate certs[] =
(X509Certificate[])req.getAttribute("javax.net.ssl.peer_certificates");
Cheers,
Eoghan
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Thanks Fred,
A few points about this patch ...
1. We've aimed to maintain a clean separation between the plaintext HTTP
support in o.a.c.t.http.JettyHTTPDestination and the HTTPS logic in
o.a.c.t.https.JettySslListenerFactory (similarly for
o.a.c.t.http.HTTPConduit and o.a.c.t.https.HttpsURLConnectionFactory).
Can you move your additions to JettyHTTPDestination to
JettySslListenerFactory so as to avoid breaking this?
2. Unfortunately we have duplication of the JettyHTTPDestination code
across the http and http2 modules. This is obviously badness, and we
plan to address it, but in the meantime all changes to http must be
manually reflected in http2 also.
Similarly for the servlet transport, though instead of a straight copy,
in this case you'd be using a different mechanism for retrieving the
cipher suite and peer cert (e.g. for Tomcat, probably the
org.apache.tomcat.util.net.SSLSupport mechanism, dunno about other
containers).
3. Dunno if you've had a chance to look at Java5 annotations, but now
that I see your TLSSessionContract.*_REQUIRED fields I think you can
achieve what you want here, and a lot more, in a much cleaner way with
annotations.
Instead of the concept of a string "contractID", as a textual
representation of what's supported and required in the "contract", why
not just use the native Java mechanism, i.e. an annotated class or
interface?
For example ...
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
public @interface Required {
}
import java.security.cert.Certificate;
public interface TLSSessionContext {
Certificate[] getPeerCertificateChain();
Certificate getTrustPoint();
@Required
String getChiperSuite();
}
Now here's the pay-off ... in the ContextInfo.put(), you could *enforce*
the requirement for a CipherSuite in a very generic way ... of the top
of my head something like:
public class ContextInfo {
public <T> T put(String key, T value) {
Method[] methods = value.getClass().getMethods()
for (Method m : methods) {
if (m.getName().startsWith("get")
&& m.isAnnotationPresent(Required.class)) {
try {
if (m.invoke(value, null) == null) {
throw new MissingRequiredContext("non-null " +
m.getName() + " required");
}
} catch (InvocationTargetException ite) {
// and so on for other exceptions ...
}
}
}
return value.getClass().cast(map.put(key, value));
}
//...
}
4. I see you use the GNU C++ style of:
returnType
methodName();
as opposed to the more normal Java style:
returnType methodName();
It doesn't break the checkstyle/PMD targets, but in the interests of
consistency with 20-ish KLOCs already in the CXF repo, why not just use
the Java style? Especially when changing a pre-existing source file.
Another minor stylistic point ... we tend to use import as opposed to
fully-qualify classes (i.e. "import java.security.cert.Certificate; ...
public static final Pair<String, Class<Certificate>> TRUST_POINT" as
opposed to "public static final Pair<java.lang.String,
Class<java.security.cert.Certificate>> TRUST_POINT").
BTW, I've absolutely no interest in a my-style-is-better-than-yours
flame war. I've seen far too much time burned on that in other projects.
So I really don't care what style is used, as long as its consistent
through-out the source tree.
Cheers,
Eoghan
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 05 March 2007 14:23
> To: cxf-dev@incubator.apache.org
> Subject: Re: Accessing Connection-based info from the transport
>
> Sorry -- under CXF-445.
>
> https://issues.apache.org/jira/browse/CXF-445
>
> On Mar 5, 2007, at 7:38 AM, Glynn, Eoghan wrote:
>
> >
> > Fred,
> >
> > Where did you submit the patch to?
> >
> > /Eoghan
> >
> >> -----Original Message-----
> >> From: Fred Dushin [mailto:fred@dushin.net]
> >> Sent: 05 March 2007 11:30
> >> To: cxf-dev@incubator.apache.org
> >> Subject: Re: Accessing Connection-based info from the transport
> >>
> >> Thanks, Eoghan.
> >>
> >> I can't really speak to the IP Address issue you raise --
> right now
> >> what I'm really concerned about is TLS-related
> information, which in
> >> the case of the Jetty implementation, is available on off the
> >> SSLSession. The local and peer IP addresses are available for the
> >> asking there, too, but currently I have no need for them
> (though I'd
> >> certainly be open to exposing this information to anyone
> downstream).
> >>
> >> As for the aesthetic issue about whether it's easier to
> design a new
> >> struct to carry this information, for each type of
> information, I've
> >> submitted a patch which I think fairly effectively avoids
> having to
> >> do this, and I'd argue it's no less usable or readable on
> the part of
> >> the producer or consumer of this information. You'll see patterns
> >> like
> >>
> >> ContextInfo info = message.get(TLSSessionContract.class);
> >> java.security.cert.Certificate[] peerCerts = info.get
> >> (TLSSessionContract.PEER_CERTIFICATES);
> >>
> >> and off you go. This is in contrast to something like:
> >>
> >> TLSSessionInfo info = message.get(TLSSessionInfo.class);
> >> java.security.cert.Certificate[] peerCerts =
> >> info.getPeerCertificates();
> >>
> >> but it has the advantage that it's slightly more future-proofed.
> >> E.g., in the latter case, if TLSSessionInfo changes, then
> >> implementations will fail to compile. And of course the type
> >> (ContextInfo) has general applicability outside of my
> myopic needs at
> >> present.
> >>
> >> Of course, I'm not a committer here, so feel free to ignore the
> >> patch. If this forum seriously feels the former approach is a
> >> detriment to the project, I can easily retrofit the
> approach, but I
> >> think that would be unfortunate. The former approach is
> really a lot
> >> simpler and cleaner, IMO.
> >>
> >> Please let me know ASAP.
> >>
> >> Thanks,
> >> -Fred
> >>
> >
>
>
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
Sorry -- under CXF-445.
https://issues.apache.org/jira/browse/CXF-445
On Mar 5, 2007, at 7:38 AM, Glynn, Eoghan wrote:
>
> Fred,
>
> Where did you submit the patch to?
>
> /Eoghan
>
>> -----Original Message-----
>> From: Fred Dushin [mailto:fred@dushin.net]
>> Sent: 05 March 2007 11:30
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Accessing Connection-based info from the transport
>>
>> Thanks, Eoghan.
>>
>> I can't really speak to the IP Address issue you raise --
>> right now what I'm really concerned about is TLS-related
>> information, which in the case of the Jetty implementation,
>> is available on off the SSLSession. The local and peer IP
>> addresses are available for the asking there, too, but
>> currently I have no need for them (though I'd certainly be
>> open to exposing this information to anyone downstream).
>>
>> As for the aesthetic issue about whether it's easier to
>> design a new struct to carry this information, for each type
>> of information, I've submitted a patch which I think fairly
>> effectively avoids having to do this, and I'd argue it's no
>> less usable or readable on the part of the producer or
>> consumer of this information. You'll see patterns like
>>
>> ContextInfo info = message.get(TLSSessionContract.class);
>> java.security.cert.Certificate[] peerCerts = info.get
>> (TLSSessionContract.PEER_CERTIFICATES);
>>
>> and off you go. This is in contrast to something like:
>>
>> TLSSessionInfo info = message.get(TLSSessionInfo.class);
>> java.security.cert.Certificate[] peerCerts =
>> info.getPeerCertificates();
>>
>> but it has the advantage that it's slightly more future-proofed.
>> E.g., in the latter case, if TLSSessionInfo changes, then
>> implementations will fail to compile. And of course the type
>> (ContextInfo) has general applicability outside of my myopic
>> needs at present.
>>
>> Of course, I'm not a committer here, so feel free to ignore
>> the patch. If this forum seriously feels the former approach
>> is a detriment to the project, I can easily retrofit the
>> approach, but I think that would be unfortunate. The former
>> approach is really a lot simpler and cleaner, IMO.
>>
>> Please let me know ASAP.
>>
>> Thanks,
>> -Fred
>>
>
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Fred,
Where did you submit the patch to?
/Eoghan
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 05 March 2007 11:30
> To: cxf-dev@incubator.apache.org
> Subject: Re: Accessing Connection-based info from the transport
>
> Thanks, Eoghan.
>
> I can't really speak to the IP Address issue you raise --
> right now what I'm really concerned about is TLS-related
> information, which in the case of the Jetty implementation,
> is available on off the SSLSession. The local and peer IP
> addresses are available for the asking there, too, but
> currently I have no need for them (though I'd certainly be
> open to exposing this information to anyone downstream).
>
> As for the aesthetic issue about whether it's easier to
> design a new struct to carry this information, for each type
> of information, I've submitted a patch which I think fairly
> effectively avoids having to do this, and I'd argue it's no
> less usable or readable on the part of the producer or
> consumer of this information. You'll see patterns like
>
> ContextInfo info = message.get(TLSSessionContract.class);
> java.security.cert.Certificate[] peerCerts = info.get
> (TLSSessionContract.PEER_CERTIFICATES);
>
> and off you go. This is in contrast to something like:
>
> TLSSessionInfo info = message.get(TLSSessionInfo.class);
> java.security.cert.Certificate[] peerCerts =
> info.getPeerCertificates();
>
> but it has the advantage that it's slightly more future-proofed.
> E.g., in the latter case, if TLSSessionInfo changes, then
> implementations will fail to compile. And of course the type
> (ContextInfo) has general applicability outside of my myopic
> needs at present.
>
> Of course, I'm not a committer here, so feel free to ignore
> the patch. If this forum seriously feels the former approach
> is a detriment to the project, I can easily retrofit the
> approach, but I think that would be unfortunate. The former
> approach is really a lot simpler and cleaner, IMO.
>
> Please let me know ASAP.
>
> Thanks,
> -Fred
>
Re: Accessing Connection-based info from the transport
Posted by Fred Dushin <fr...@dushin.net>.
Thanks, Eoghan.
I can't really speak to the IP Address issue you raise -- right now
what I'm really concerned about is TLS-related information, which in
the case of the Jetty implementation, is available on off the
SSLSession. The local and peer IP addresses are available for the
asking there, too, but currently I have no need for them (though I'd
certainly be open to exposing this information to anyone downstream).
As for the aesthetic issue about whether it's easier to design a new
struct to carry this information, for each type of information, I've
submitted a patch which I think fairly effectively avoids having to
do this, and I'd argue it's no less usable or readable on the part of
the producer or consumer of this information. You'll see patterns like
ContextInfo info = message.get(TLSSessionContract.class);
java.security.cert.Certificate[] peerCerts = info.get
(TLSSessionContract.PEER_CERTIFICATES);
and off you go. This is in contrast to something like:
TLSSessionInfo info = message.get(TLSSessionInfo.class);
java.security.cert.Certificate[] peerCerts = info.getPeerCertificates();
but it has the advantage that it's slightly more future-proofed.
E.g., in the latter case, if TLSSessionInfo changes, then
implementations will fail to compile. And of course the type
(ContextInfo) has general applicability outside of my myopic needs at
present.
Of course, I'm not a committer here, so feel free to ignore the
patch. If this forum seriously feels the former approach is a
detriment to the project, I can easily retrofit the approach, but I
think that would be unfortunate. The former approach is really a lot
simpler and cleaner, IMO.
Please let me know ASAP.
Thanks,
-Fred
RE: Accessing Connection-based info from the transport
Posted by "Glynn, Eoghan" <eo...@iona.com>.
+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
names.
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
IP-based.
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
together".
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 java.net.InetAddress and java.security.cert.Certificate, it would
probably be a lot easier to just write a few Java interfaces directly.
Cheers,
Eoghan
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 02 March 2007 17:13
> To: cxf-dev@incubator.apache.org
> 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 {
> java.security.cert.Certificate[] 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
>