Hi Cam,
Cam Bazz wrote:
> yes, I have done the isSecure test, and that is exactly the case. I am
> however now using apache based authentication. Another little thing I
> tried was to enable the "Auth Pass Through"
> (Indicate that the network listener receives traffic from an
> SSL-terminating proxy server) - when i did that, the site worked, but
> for some reason getRemoteAddr() would throw an exception. - (the login
> servlet logs remote ip numbers upon successful login)
>
I don't think the authpassthrough approach would work in conjunction
with Apache and mod_jk. It is designed to handle the case where a LB
proxies requests to GlassFish over HTTP (instead of mod_jk) after adding
any information about the original request as HTTP request headers. The
default authpassthrough implementation works in conjunction with Sun's
LB plugin and determines the client's SSL certificate chain, SSL
keysize, and client IP from HTTP request headers with names
"Proxy-auth-cert", "Proxy-keysize", and "Proxy-ip".
Jan
> Best Regards,
> -C.B.
>
> On Sat, Feb 27, 2010 at 5:09 AM, Jan Luehe <Jan.Luehe_at_sun.com> wrote:
>
>> glassfish_at_javadesktop.org wrote:
>>
>> Hello Jan,
>>
>> I am having similar troubles too.I have set the cookieSecure="false" to
>> circumvent this problem. appearently switching from http -> https it would
>> keep the same cookie, but a secure version, when switching https -> http, it
>> would then get a new cookie. (since the secure cookie is used once, i guess)
>>
>>
>>
>> If the request that initiated the session came in over https (or was proxied
>> to the
>> backend over plain mod_jk, but with extra (header) info from which the
>> backend could determine that the original request received at the frontend
>> had been secure), then the session tracking cookie will also be marked as
>> secure,
>> which has the effect that it will be included only with subsequent client
>> requests
>> that are also secure.
>>
>> You mentioned:
>>
>>
>>
>> 2. Is your LB properly configured to forward any SSL related info to
>> the backend, so that the backend can determine whether the original
>> request (between the client and the LB) came in over http or https?
>>
>>
>> I was not able to get mod_jk working with ssl. How do we exactly configure
>> the LB (apache + mod_jk) in this case, to forward SSL related info to the
>> backend?
>>
>>
>>
>> I think this is done by the following config that is mentioned in the docs:
>>
>> # Should mod_jk send SSL information (default is On)
>> JkExtractSSL On
>> # What is the indicator for SSL (default is HTTPS)
>> JkHTTPSIndicator HTTPS
>> # What is the indicator for SSL session (default is SSL_SESSION_ID)
>> JkSESSIONIndicator SSL_SESSION_ID
>> # What is the indicator for client SSL cipher suit (default is SSL_CIPHER)
>> JkCIPHERIndicator SSL_CIPHER
>> # What is the indicator for the client SSL certificate? (default is
>> SSL_CLIENT_CERT)
>> JkCERTSIndicator SSL_CLIENT_CERT
>>
>> I have followed
>> wiki.glassfish.java.net/attach/AdministrationGuide/SJSASEEAG.pdf (page 113
>> and 114) - but the apache would not allow https://site.com:443, but it would
>> let http://site.com:443 -
>>
>>
>> I have done extensive log file watching and figured out that the workers are
>> working ok, but the SSL info was not forwarded.
>>
>>
>>
>> Are you saying that you've configured Apache in SSL-terminating mode,
>> configured a single, non-secure mod_jk listener on the backend, set
>> JkExtractSSL
>> to "On" (the default mode), and are still not seeing any SSL info getting
>> transmitted to the backend?
>>
>> One easy test would be to send an https request to a Servlet, and have the
>> Servlet
>> call ServletRequest#isSecure: if this method returns "true", then you know
>> that
>> SSL info has been transmitted to the backend (because otherwise,
>> ServletRequest#isSecure would have returned "false").
>>
>> Thanks,
>>
>> Jan
>>
>> Best Regards,
>> -C.B.
>> [Message sent by forum member 'cambazz' (cambazz_at_gmail.com)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=389032
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>