Tomcat Displaying Login Page before redirecting to https

[Jerry Malcolm]

I have a standalone tomcat. TC is configured to redirect any port 80
requests to https/443.  It works fine on pages that aren't protected by
web.xml security constraints.  However, if a page is protected, the
login page appears while still in non-ssl http mode. For years, I've had
httpd sitting in front of TC handling the ssl stuff.  So this is new
territory for us.  Have we got something misconfigured or perhaps out of
order that is pushing the ssl redirect down in the process?  Suggestions?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

On 12/01/2021 00:00, Jerry Malcolm wrote:
> I have a standalone tomcat. TC is configured to redirect any port 80
> requests to https/443.  It works fine on pages that aren't protected by
> web.xml security constraints.  However, if a page is protected, the
> login page appears while still in non-ssl http mode. For years, I've had
> httpd sitting in front of TC handling the ssl stuff.  So this is new
> territory for us.  Have we got something misconfigured or perhaps out of
> order that is pushing the ssl redirect down in the process?  Suggestions?

How have you configured the http -> https redirect?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jerry Malcolm]

On 1/11/2021 6:11 PM, Mark Thomas wrote:

> On 12/01/2021 00:00, Jerry Malcolm wrote:
>> I have a standalone tomcat. TC is configured to redirect any port 80
>> requests to https/443.  It works fine on pages that aren't protected by
>> web.xml security constraints.  However, if a page is protected, the
>> login page appears while still in non-ssl http mode. For years, I've had
>> httpd sitting in front of TC handling the ssl stuff.  So this is new
>> territory for us.  Have we got something misconfigured or perhaps out of
>> order that is pushing the ssl redirect down in the process?  Suggestions?
> How have you configured the http -> https redirect?
>
> Mark
>

Hi Mark, This is a snippit from my main web.xml file:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
   version="3.1">


<security-constraint>
  <web-resource-collection>
     <web-resource-name>Protected Context</web-resource-name>
     <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

<filter>
   <filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
   <init-param>

>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[markt]

On 12/01/2021 00:45, Jerry Malcolm wrote:

> On 1/11/2021 6:11 PM, Mark Thomas wrote:
>> On 12/01/2021 00:00, Jerry Malcolm wrote:
>>> I have a standalone tomcat. TC is configured to redirect any port 80
>>> requests to https/443.  It works fine on pages that aren't protected by
>>> web.xml security constraints.  However, if a page is protected, the
>>> login page appears while still in non-ssl http mode. For years, I've had
>>> httpd sitting in front of TC handling the ssl stuff.  So this is new
>>> territory for us.  Have we got something misconfigured or perhaps out of
>>> order that is pushing the ssl redirect down in the process? 
>>> Suggestions?
>> How have you configured the http -> https redirect?
>>
>> Mark
>>
> Hi Mark, This is a snippit from my main web.xml file:
>
> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
>   version="3.1">
>
>
> <security-constraint>
>  <web-resource-collection>
>     <web-resource-name>Protected Context</web-resource-name>
>     <url-pattern>/*</url-pattern>
>  </web-resource-collection>
>  <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>  </user-data-constraint>
> </security-constraint>
>
> <filter>
>   <filter-name>CorsFilter</filter-name>
> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
>   <init-param>

Hi Jerry,

I suspect the issue is how security constraints are merged. URL patterns
 in security constraints behave differently to URL patterns in Servlets
and Filters. For security constraints you take every constraint that
matches the URL pattern (and the HTTP method but I'm ignoring that for
simplicity) and merge them according to the rules in section 13.8.1. The
key part is:

"A security constraint that does not contain a user-data-constraint
shall combine with other user-data-constraint to cause the unprotected
connection type to be an accepted connection type."

To put it another way, if you want everything to redirect from http to
https, every security constraint needs to include a transport-guarantee
of CONFIDENTIAL.

HTH,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jerry Malcolm]

Mark,

It definitely helped.  Works like a charm now.

I figure I only have about 10 more years of doing this stuff to start
becoming reasonably educated in all of the ins and outs of tomcat.  The
deeper I get, the more I realize how many issues and problems you folks
have had to deal with and resolve over the years.  I really appreciate
all of the help you and your team have been to me as I attempt to get
everything working.

Jerry

On 1/12/2021 1:49 AM, Mark Thomas wrote:

> On 12/01/2021 00:45, Jerry Malcolm wrote:
>> On 1/11/2021 6:11 PM, Mark Thomas wrote:
>>> On 12/01/2021 00:00, Jerry Malcolm wrote:
>>>> I have a standalone tomcat. TC is configured to redirect any port 80
>>>> requests to https/443.  It works fine on pages that aren't protected by
>>>> web.xml security constraints.  However, if a page is protected, the
>>>> login page appears while still in non-ssl http mode. For years, I've had
>>>> httpd sitting in front of TC handling the ssl stuff.  So this is new
>>>> territory for us.  Have we got something misconfigured or perhaps out of
>>>> order that is pushing the ssl redirect down in the process?
>>>> Suggestions?
>>> How have you configured the http -> https redirect?
>>>
>>> Mark
>>>
>> Hi Mark, This is a snippit from my main web.xml file:
>>
>> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
>>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
>> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
>>    version="3.1">
>>
>>
>> <security-constraint>
>>   <web-resource-collection>
>>      <web-resource-name>Protected Context</web-resource-name>
>>      <url-pattern>/*</url-pattern>
>>   </web-resource-collection>
>>   <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>   </user-data-constraint>
>> </security-constraint>
>>
>> <filter>
>>    <filter-name>CorsFilter</filter-name>
>> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
>>    <init-param>
> Hi Jerry,
>
> I suspect the issue is how security constraints are merged. URL patterns
>   in security constraints behave differently to URL patterns in Servlets
> and Filters. For security constraints you take every constraint that
> matches the URL pattern (and the HTTP method but I'm ignoring that for
> simplicity) and merge them according to the rules in section 13.8.1. The
> key part is:
>
> "A security constraint that does not contain a user-data-constraint
> shall combine with other user-data-constraint to cause the unprotected
> connection type to be an accepted connection type."
>
> To put it another way, if you want everything to redirect from http to
> https, every security constraint needs to include a transport-guarantee
> of CONFIDENTIAL.
>
> HTH,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]