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
