Bug 1369085 - Values for rhq.server.tomcat.security.client-auth-mode and rhq.communications.connector.security.client-auth-mode are not validated
Summary: Values for rhq.server.tomcat.security.client-auth-mode and rhq.communications...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Core Server, Usability
Version: JON 3.3.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER01
: JON 3.3.8
Assignee: Josejulio Martínez
QA Contact: Filip Brychta
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-22 13:03 UTC by Filip Brychta
Modified: 2017-02-16 18:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-16 18:45:19 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1369081 0 high CLOSED Confusion between rhq.server.tomcat.security.client-auth-mode and rhq.communications.connector.security.client-auth-mode... 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHEA-2017:0285 0 normal SHIPPED_LIVE Red Hat JBoss Operations Network 3.3.8 bug fix update 2017-02-16 23:44:22 UTC

Internal Links: 1369081

Description Filip Brychta 2016-08-22 13:03:46 UTC
Description of problem:
Because of bz1369081 it's possible to put incorrect values to rhq.server.tomcat.security.client-auth-mode and rhq.communications.connector.security.client-auth-mode properties.
Server starts without any error even with incorrect values so user might incorrectly think the client auth is enabled even though it is not because of typo in property value.

Version-Release number of selected component (if applicable):
JON3.3.x

How reproducible:
Always

Steps to Reproduce:
1. set up two way ssl agent <> server communication
2. set rhq.server.tomcat.security.client-auth-mode=tottalyIncorrect
3. start JON server

Actual results:
Server is started correctly without any error. 

Expected results:
There should be error visible that given property is incorrect and client auth is not enabled.


Additional info:

Comment 1 Josejulio Martínez 2016-12-07 20:23:48 UTC
It already warns when setting rhq.communications.connector.security.client-auth-mode to 'tottalyIncorrect' (and using a secure transport method).

13:46:00,778 WARN  [org.rhq.enterprise.communications.ServiceContainerConfiguration] (pool-6-thread-1) {ServiceContainerConfiguration.invalid-client-auth}The [rhq.communications.connector.security.client-auth-mode] preference specified is invalid [tottalyIncorrect] - it must be one of [none, want, need]. Setting it to [need].

It also maps true/false to need/none, see: https://github.com/rhq-project/rhq/blob/release/jon3.3.x/modules/enterprise/comm/src/main/java/org/rhq/enterprise/communications/ServiceContainerConfiguration.java#L432-L452

Do you think the warn should be changed to error?

I'll do something similar with rhq.server.tomcat.security.client-auth-mode

Comment 2 Filip Brychta 2016-12-08 10:03:02 UTC
Sorry I missed the warning. I guess correct approach for validation issues of security properties would be to log warning and default to the most strict option. Otherwise an user could easily miss the warning and server would be running in unsecured mode.

Comment 3 Josejulio Martínez 2016-12-13 05:37:18 UTC
From the other attribute ('rhq.server.tomcat.security.client-auth-mode') I need to research a bit more.
Currently that one is used directly by the https connector (see jbossas/standalone/configuration/standalone-full-xml) 
verify-client="${rhq.server.tomcat.security.client-auth-mode:false}"

I could use the DRM API to get the value, but I'm not sure if could set the value to a stricter one after starting the application server.

Comment 4 Josejulio Martínez 2017-01-05 17:08:24 UTC
'rhq.server.tomcat.security.client-auth-mode' is passed directly to EAP.

See jbossas/standalone/configuration/standalone-full.xml line 523: 
verify-client="${rhq.server.tomcat.security.client-auth-mode:false}"

It seems to be an EAP issue and not sure if we should do something about it.
I guess we could WARN, but I'm not sure we could set it up to something else at that point.

Comment 5 Filip Brychta 2017-01-06 11:41:21 UTC
Just warning in case of 'rhq.server.tomcat.security.client-auth-mode' should be fine.

Comment 6 Josejulio Martínez 2017-01-10 18:26:00 UTC
11:30:28,269 WARN  [org.rhq.enterprise.communications.ServiceContainer] (pool-6-thread-1) {ServiceContainerConfiguration.invalid-tomcat-client-auth}The [rhq.server.tomcat.security.client-auth-mode] preference specified is invalid [some_wrong_value] - it must be one of [true, false].

This warning will appear only when selecting sslservlet as transport method.

Should be fixed with this PR:
https://github.com/rhq-project/rhq/pull/284

Comment 7 Josejulio Martínez 2017-01-14 05:59:49 UTC
commit 78d83fb415f9cce035419e46fc4b992c151849ab
Merge: a40b39d 3404646
Author: Michael Burman <yak>
Date:   Fri Jan 13 13:43:44 2017 +0200

    Merge pull request #284 from josejulio/bugs/1369085-b
    
    WARN when setting rhq.server.tomcat.security.client-auth-mode to a va…

commit 340464602844dd75facc87d07c908fe784b2ec43
Author: Josejulio Martínez <jmartine>
Date:   Tue Jan 10 11:42:41 2017 -0600

    WARN when setting rhq.server.tomcat.security.client-auth-mode to a value different than true or false.

Comment 10 Filip Brychta 2017-01-25 13:30:25 UTC
Verified on:
JON 3.3.8.ER01

07:58:37,412 WARN  [org.rhq.enterprise.communications.ServiceContainer] (pool-6-thread-1) {ServiceContainerConfiguration.invalid-tomcat-client-auth}The [rhq.server.tomcat.security.client-auth-mode] preference specified is invalid [incorrect] - it must be one of [true, false] (case sensitive).

08:27:59,409 WARN  [org.rhq.enterprise.communications.ServiceContainerConfiguration] (pool-6-thread-1) {ServiceContainerConfiguration.invalid-client-auth}The [rhq.communications.connector.security.client-auth-mode] preference specified is invalid [incorr] - it must be one of [none, want, need]. Setting it to [need]

Comment 11 errata-xmlrpc 2017-02-16 18:45:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2017-0285.html


Note You need to log in before you can comment on or make changes to this bug.