On 01/07/2010 08:49, John-Paul Ranaudo wrote: > No we are not. If the SSL-only resources match a specific path, you can add a security-constraint which doesn't have user roles, but does have a transport-guarantee set to 'CONFIDENTIAL'.
The container will automatically upgrade a matching request to HTTPS by redirecting it to the port configured in 'redirectPort' on the HTTP connector. p > On 7/1/10, Pid <p...@pidster.com> wrote: >> On 01/07/2010 03:42, John-Paul Ranaudo wrote: >>> I have now realized the root of the problem. The cause of the problem is >>> that the load balancer will sometimes proxy an HTTPS request as an HTTP >>> request so when we send back a redirect we send it back with the wrong >>> scheme (HTTP). So here is my current configuration: >>> >>> <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" /> >>> <Connector port="443" protocol="HTTP/1.1" connectionTimeout="20000" >>> scheme="https" secure="true" /> >>> >>> Port 443 is not really handling the SSL because the load balancer is. I >>> set >>> "secure" to true to mark the connections as secure to tomcat and not >>> needing >>> SSL decryption as recommended. >>> >>> The one framework in which uses HTTPS will send most request as HTTPS >>> however the load balancer (for unknown reasons) proxies the request as >>> HTTP >>> (port 80). So now when we send a redirect it's to HTTP (port 80) not HTTPS >>> (port 443). It should be port 443. >>> >>> Any idea how I can handle this in a connector configuration? >>> >>> My first thought is to create two virtual hosts which will then have 2 >>> different server.xml's. If I do this I can tell tomcat to proxy all HTTP >>> (port 80) requests to port 443 but only for that one virtual host (which >>> contains the problem framework). >>> >>> Any thoughts? >>> >>> Thanks and Regards, >>> >>> John-Paul Ranaudo >>> Application Architect >>> >>> On Fri, Jun 25, 2010 at 2:22 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >>> John-Paul, >>> >>> On 6/25/2010 1:40 PM, John-Paul Ranaudo wrote: >>>>>> Ok, so I am assuming I do not have to setup SSL (certificates etc) >>>>>> since >>> my >>>>>> load balancer is decoding the connection. So even if the load balancer >>>>>> is >>>>>> "decoding" the connection I still have to have SSLEnabled="true"? >>> >>> No, Pid was saying that setting one of the two options (SSLEnabled and >>> secure) to "true" makes sense... setting both to "false" is not >>> particularly useful. >>> >>>>>> However if >>>>>> I do, does this not make Tomcat try and decode the "connection"? >>> >>> Yes, setting SSLEnabled="true" will make the connector try to perform >>> the decryption. >>> >>>>>> *Which is the root of my problem. How to use the HTTPS protocol without >>>>>> having Tomcat decrypt the connection since the load balancer has done >>> this >>>>>> for me. * >>> >>> It sounds like you just want Tomcat to know that the connection is >>> secure, but without actually doing the decryption. You should be able to >>> do it like this: >>> >>> <Connector >>> port="443" <- this is the port that the LB talks to >>> protocol="HTTP/1.1" >>> connectionTimeout="20000" >>> scheme="https" <- so request.getScheme returns correct value >>> secure="true" <- so request.isSecure returns correct value >>> /> >>> >>> There's no need to set SSLProtocol or SSLEnabled (you're not using SSL, >>> remember), they will default to "false". >>> >>>>>> The link to the documentation is correct. However the properties of the >>>>>> connector are confusing to me. For example "SSLEnabled" if fairly >>>>>> obvious >>>>>> but "secure" it confusing. Not sure under what context I need to set >>> this. >>> >>> You can set these to different values, for instance, to instruct the >>> server to report connections as secure even when they aren't actually >>> tunneled through SSL (as above). >>> >>>>>> The application always uses relative paths so whatever protocol the >>>>>> framework is using will be what is returned in the page. >>> >>> Good. How about redirects? >>> >>>>>> I have also tried setting the redirect port thinking I can redirect >>> requests >>>>>> to 443 to the port 80 internally and scheme to 'https'. This actually >>>>>> had >>>>>> the effect of making one framework (the one with https) work but broke >>> the >>>>>> other. >>> >>> The redirect port is only used when the server decides that a webapp >>> requires a secure connection (see <transport-guarantee> in web.xml), and >>> the server issues a redirect to the client to upgrade the connection to >>> HTTPS. The default is 443, so if a client arrives on port 80, they will >>> be redirected to the same URL except with https:// on the front and the >>> port added if it's not the default of 443. >>> >>> Now, you have to remember that the port number that does out attached to >>> a redirect URL (say, https://myhost:443/foo/bar) is probably the port on >>> the load-balancer the client will hit, not necessarily the port on the >>> local machine. The following configuration is perfectly legitimate: >>> >>> <!-- non-secure connector --> >>> <Connector >>> port="8080" >>> protocol="HTTP/1.1" >>> connectionTimeout="20000" >>> redirectPort="443" >>> /> >>> >>> <!-- secure connector --> >>> <Connector >>> port="8443" >>> protocol="HTTP/1.1" >>> connectionTimeout="20000" >>> scheme="https" <- so request.getScheme returns correct value >>> secure="true" <- so request.isSecure returns correct value >>> /> >>> >>> As you see, redirectPort is set to a port that isn't being handled by >>> Tomcat. That's okay, because the load-balancer is presumably handling >>> requests to myhost:443, terminating the SSL, and proxying the cleartext >>> HTTP request to the "8443" connector, which then reports secure="true" >>> to anyone who asks. >> >> Are you using a transport-guarantee element in your web.xml? >> >> >> p >> >> >>> Hope that helps, >>> -chris >>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >> >> >> >
signature.asc
Description: OpenPGP digital signature
