Michael Decker wrote:
The AJP protocol will convery the SSL information to tomcat fairly
seamlessly, the idea being from the web-app's point of view it can't
tell the difference between an Apache fronted HTTP session and one
coming in via a AJP connector.
You mean, that the session will be created by apache not by tomcat?
We're getting ambigious here. Maybe I should have used the term "HTTP
request response cycle" instead of "HTTP session".
An SSL session to me is a single TLS/SSL connection that securely sets
up a network connection to exchange data. At the start of this a key
exchange is done and the SSL session data maybe cached by mod_ssl into a
file like /opt/apache/logs/ssl_scache.{dir,pag} for later use. SSL
session data can be seen with:
openssl s_client -connect www.yourdomain.com:443
However I think the only session you are really talking about, is an
application session which is generally what HTTP Cookies are used for.
My problem is, that the application session (set by cookie or url
parameter) is not associated with the SSL session. And I hope, there is
an easy way to that.
I dont understand why you want to connect to two (under my definition of
each explained above). It is not normal to connect the SSL session in
this way, as the HTTP protocol may (or may not) use the same SSL session
details during the next request, the client may (or may not) support
persistent connections. The SSL session cache is a performance
optimization, not something an application gets to see or use directly.
It more normal to issue client certificates to your userbase and
validate those certificates with a per-website certificate authority.
In which case the certificate will have an "Issue Number" and it is this
issue number you can use as an authentication token (providing the
certificate has passed validity testing, I'm sure both apache and tomcat
can help with your application specific validity rules).
Even if you have a self-signed CA on your website a regular Cookie based
login mechanism should be secure enough for most applications. The
JSESSIONID cookie is the primary mechanism for session handling with
most containers.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
