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 <pid@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 HT=
TP
>>> request so when we send back a redirect we send it back with the wron=
g
>>> scheme (HTTP). So here is my current configuration:
>>>
>>> <Connector port=3D"80" protocol=3D"HTTP/1.1" connectionTimeout=3D"200=
00" />
>>> <Connector port=3D"443" protocol=3D"HTTP/1.1" connectionTimeout=3D"20=
000"
>>> scheme=3D"https" secure=3D"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 a=
s
>>> 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 H=
TTP
>>> (port 80) requests to port 443 but only for that one virtual host (wh=
ich
>>> 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 <
>>> chris@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 bala=
ncer
>>>>>> is
>>>>>> "decoding" the connection I still have to have SSLEnabled=3D"true"=
?
>>>
>>> No, Pid was saying that setting one of the two options (SSLEnabled an=
d
>>> 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=3D"true" will make the connector try to perfo=
rm
>>> the decryption.
>>>
>>>>>> *Which is the root of my problem. How to use the HTTPS protocol wi=
thout
>>>>>> having Tomcat decrypt the connection since the load balancer has
d=
one
>>> 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=3D"443" <- this is the port that the LB talks to
>>> protocol=3D"HTTP/1.1"
>>> connectionTimeout=3D"20000"
>>> scheme=3D"https" <- so request.getScheme returns correct value
>>> secure=3D"true" <- so request.isSecure returns correct value
>>> />
>>>
>>> There's no need to set SSLProtocol or SSLEnabled (you're not using SS=
L,
>>> remember), they will default to "false".
>>>
>>>>>> The link to the documentation is correct. However the properties
o=
f the
>>>>>> connector are confusing to me. For example "SSLEnabled" if fairly
>>>>>> obvious
>>>>>> but "secure" it confusing. Not sure under what context I need to
s=
et
>>> 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 th=
e
>>>>>> 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 redirec=
t
>>> requests
>>>>>> to 443 to the port 80 internally and scheme to 'https'. This actua=
lly
>>>>>> had
>>>>>> the effect of making one framework (the one with https) work but
b=
roke
>>> 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 wi=
ll
>>> be redirected to the same URL except with https:// on the front and t=
he
>>> 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 th=
e
>>> local machine. The following configuration is perfectly legitimate:
>>>
>>> <!-- non-secure connector -->
>>> <Connector
>>> port=3D"8080"
>>> protocol=3D"HTTP/1.1"
>>> connectionTimeout=3D"20000"
>>> redirectPort=3D"443"
>>> />
>>>
>>> <!-- secure connector -->
>>> <Connector
>>> port=3D"8443"
>>> protocol=3D"HTTP/1.1"
>>> connectionTimeout=3D"20000"
>>> scheme=3D"https" <- so request.getScheme returns correct value
>>> secure=3D"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 clearte=
xt
>>> HTTP request to the "8443" connector, which then reports secure=3D"tr=
ue"
>>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>
>>
>>
>=20
|