[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Will Tatam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Will Tatam commented on WFLY-3636:
----------------------------------
Please could you provide an update on your progress on this feature?
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri edited comment on JBJCA-1329 at 8/25/16 8:21 AM:
-----------------------------------------------------------------
The error code is actually in the cause Exception.We should just rethrow this instead of encapsulating it inside another Exception of the same type. I've submitted 2 PRs (1.2 and 1.3 branches) fixing this
https://github.com/ironjacamar/ironjacamar/pull/564
https://github.com/ironjacamar/ironjacamar/pull/563
Regarding 15.4.4, it's in fact what we are doing here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
was (Author: maeste):
The error code is actually in the cause Exception.We should just rethrow this instead of encapsulating it inside another Exception of the same type. I've submitted 2 PRs (1.2 and 1.3 branches) fixing this
Regarding 15.4.4, it's in fact what we are doing here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7000) Batch jobs from installed modules should be detected for non-batch app
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-7000?page=com.atlassian.jira.plugin.... ]
Cheng Fang reassigned WFLY-7000:
--------------------------------
Assignee: James Perkins (was: Cheng Fang)
> Batch jobs from installed modules should be detected for non-batch app
> ----------------------------------------------------------------------
>
> Key: WFLY-7000
> URL: https://issues.jboss.org/browse/WFLY-7000
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Mincong Huang
> Assignee: James Perkins
>
> Hibernate Search is creating a batch job which embedded in a WildFly module. Any user of Hibernate Search should be able to the launch this batch job, no matter if they're using a batch-app. However, it seems that jobs are only resolvable for batch-app. More explicitly, WildFly requires deployed web-app to have the below structure to enable the job resolver:
> META-INF/batch-jobs
> For those who don't have this batch folder in their webapp, they cannot use the jobs from installed module. And an error "JBERET000601: Failed to get job xml file for job" will be raised.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1329:
----------------------------------------
The error code is actually in the cause Exception.We should just rethrow this instead of encapsulating it inside another Exception of the same type. I've submitted 2 PRs (1.2 and 1.3 branches) fixing this
Regarding 15.4.4, it's in fact what we are doing here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-621) Can Client Cert authentication trigger SSLSession renegotiation?
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-621:
------------------------------------
Summary: Can Client Cert authentication trigger SSLSession renegotiation?
Key: ELY-621
URL: https://issues.jboss.org/browse/ELY-621
Project: WildFly Elytron
Issue Type: Feature Request
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta9
This could be an option to enable demanding client verification for an established connection but depending on the application being accessed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7001) CLI 'deployment-info --headers' throws errors in standalone mode
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7001?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-7001:
----------------------------------------
Assignee: Bartosz Baranowski (was: Jason Greene)
> CLI 'deployment-info --headers' throws errors in standalone mode
> ----------------------------------------------------------------
>
> Key: WFLY-7001
> URL: https://issues.jboss.org/browse/WFLY-7001
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> In standalone mode of jboss-cli, the command: 'deployment-info --headers' throws Java exceptions instead of a proper problem description.
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> {code}
> Tab complete does not work beyond '--headers=' and starts working again after '\{' is typed.
> *Example*:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers<TAB>=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={<TAB>
> allow-resource-service-restart rollback-on-runtime-failure
> blocking-timeout rollout
> {code}
> *Steps to reproduce*:
> Standalone:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> [standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={}
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> jboss-kitchensink-ml-ear.ear jboss-kitchensink-ml-ear.ear true false STOPPED
> jboss-kitchensink.war jboss-kitchensink.war true false STOPPED
> jboss-modules.jar jboss-modules.jar true false STOPPED
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7001) CLI 'deployment-info --headers' throws errors in standalone mode
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7001?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-7001:
-------------------------------------
Description:
In standalone mode of jboss-cli, the command: 'deployment-info --headers' throws Java exceptions instead of a proper problem description.
{code:bash}
[standalone@localhost:9990 /] deployment-info --headers
Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
{code}
Tab complete does not work beyond '--headers=' and starts working again after '\{' is typed.
*Example*:
{code:bash}
[standalone@localhost:9990 /] deployment-info --headers<TAB>=<TAB><TAB>
Failed to handle 'deployment-info --headers=': newValue is null
[standalone@localhost:9990 /] deployment-info --headers={<TAB>
allow-resource-service-restart rollback-on-runtime-failure
blocking-timeout rollout
{code}
*Steps to reproduce*:
Standalone:
{code:bash}
[standalone@localhost:9990 /] deployment-info --headers
Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
[standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
Failed to handle 'deployment-info --headers=': newValue is null
[standalone@localhost:9990 /] deployment-info --headers={}
NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
jboss-kitchensink-ml-ear.ear jboss-kitchensink-ml-ear.ear true false STOPPED
jboss-kitchensink.war jboss-kitchensink.war true false STOPPED
jboss-modules.jar jboss-modules.jar true false STOPPED
{code}
> CLI 'deployment-info --headers' throws errors in standalone mode
> ----------------------------------------------------------------
>
> Key: WFLY-7001
> URL: https://issues.jboss.org/browse/WFLY-7001
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
>
> In standalone mode of jboss-cli, the command: 'deployment-info --headers' throws Java exceptions instead of a proper problem description.
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> {code}
> Tab complete does not work beyond '--headers=' and starts working again after '\{' is typed.
> *Example*:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers<TAB>=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={<TAB>
> allow-resource-service-restart rollback-on-runtime-failure
> blocking-timeout rollout
> {code}
> *Steps to reproduce*:
> Standalone:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> [standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={}
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> jboss-kitchensink-ml-ear.ear jboss-kitchensink-ml-ear.ear true false STOPPED
> jboss-kitchensink.war jboss-kitchensink.war true false STOPPED
> jboss-modules.jar jboss-modules.jar true false STOPPED
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-6999.
------------------------------------
Resolution: Rejected
> client authentication not behaving correctly?
> ---------------------------------------------
>
> Key: WFLY-6999
> URL: https://issues.jboss.org/browse/WFLY-6999
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.2.Final
> Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
> Reporter: Pascal Knüppel
> Assignee: Darran Lofthouse
>
> I am currently reading the wildfly 9 documentation and I started to test some things and I began with client certificate authentication since I am going to need this feature in short future.
> I found a way to realize mutual authentication but this one is rather a workaround than anything else.
> For starters it is my intention to deploy a web application on an https-port that requires client authentication. Additionally I want other applications under the same port that do not require client authentication. This is a feature that does not seem to be possible eventhough the documentation uses references to the security-domain section here.
> Now I will provide my configuration how I configured my application and my wildfly server to activate client cert authentication. Note that I had to configure a second virtual host with a new port to accomplish this.
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <!--<login-config>-->
> <!--<auth-method>CLIENT-CERT</auth-method>-->
> <!--<!–<realm-name>secured-app-domain</realm-name>–>-->
> <!--</login-config>-->
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <server-instance>client-auth-server</server-instance>
> <virtual-host>client-auth-host</virtual-host>
> <!--<security-domain>secured-app-domain</security-domain>-->
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="gfi"/>
> </authentication>
> </security-realm>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="client-auth-server">
> <https-listener name="secured-https" socket-binding="client-auth-https" security-realm="SSLRealm" verify-client="REQUIRED"/>
> <host name="client-auth-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> <socket-binding name="client-auth-https" port="${jboss.https.port:8444}"/>
> {code}
> This is everything needed for client-authentication if roles are not necessary. In case of using roles I had to add the uncommented security-domain not listed in the above code.
> Now to the point:
> this configuration seems undesirable to me and I am not sure if this is really wanted like this... as you can see in *web.xml* the tag <login-config> is uncommented. This configuration is completely ignored if set. The tag <realm-name> seems to have no effect either. I can write in this field what I want it changes nothing. So I did some more research and figured that the actual correct settings should be set like this:
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server gegenüber authentifiziert. -->
> <auth-method>CLIENT-CERT</auth-method>
> <!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS SHOULD ACCOMPLISH -->
> </login-config>
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>secured-app-domain</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw"/>
> </ssl>
> </server-identities>
> </security-realm>
> ...
> <security-domain name="trust-domain">
> <jsse truststore-password="pw" truststore-url="file:${jboss.server.config.dir}/gfi.jks" client-auth="true"/>
> </security-domain>
> <security-domain name="secured-app-domain">
> <authentication>
> <login-module code="Certificate" flag="required">
> <module-option name="securityDomain" value="trust-domain"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> {code}
> This configuration should work based on this article [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...] but the configuration is completely ignored and I have access to my application without any certificates imported to my browser. Can anyone explain this behaviour it just does not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reopened WFLY-6999:
------------------------------------
> client authentication not behaving correctly?
> ---------------------------------------------
>
> Key: WFLY-6999
> URL: https://issues.jboss.org/browse/WFLY-6999
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.2.Final
> Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
> Reporter: Pascal Knüppel
> Assignee: Darran Lofthouse
>
> I am currently reading the wildfly 9 documentation and I started to test some things and I began with client certificate authentication since I am going to need this feature in short future.
> I found a way to realize mutual authentication but this one is rather a workaround than anything else.
> For starters it is my intention to deploy a web application on an https-port that requires client authentication. Additionally I want other applications under the same port that do not require client authentication. This is a feature that does not seem to be possible eventhough the documentation uses references to the security-domain section here.
> Now I will provide my configuration how I configured my application and my wildfly server to activate client cert authentication. Note that I had to configure a second virtual host with a new port to accomplish this.
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <!--<login-config>-->
> <!--<auth-method>CLIENT-CERT</auth-method>-->
> <!--<!–<realm-name>secured-app-domain</realm-name>–>-->
> <!--</login-config>-->
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <server-instance>client-auth-server</server-instance>
> <virtual-host>client-auth-host</virtual-host>
> <!--<security-domain>secured-app-domain</security-domain>-->
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="gfi"/>
> </authentication>
> </security-realm>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="client-auth-server">
> <https-listener name="secured-https" socket-binding="client-auth-https" security-realm="SSLRealm" verify-client="REQUIRED"/>
> <host name="client-auth-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> <socket-binding name="client-auth-https" port="${jboss.https.port:8444}"/>
> {code}
> This is everything needed for client-authentication if roles are not necessary. In case of using roles I had to add the uncommented security-domain not listed in the above code.
> Now to the point:
> this configuration seems undesirable to me and I am not sure if this is really wanted like this... as you can see in *web.xml* the tag <login-config> is uncommented. This configuration is completely ignored if set. The tag <realm-name> seems to have no effect either. I can write in this field what I want it changes nothing. So I did some more research and figured that the actual correct settings should be set like this:
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server gegenüber authentifiziert. -->
> <auth-method>CLIENT-CERT</auth-method>
> <!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS SHOULD ACCOMPLISH -->
> </login-config>
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>secured-app-domain</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw"/>
> </ssl>
> </server-identities>
> </security-realm>
> ...
> <security-domain name="trust-domain">
> <jsse truststore-password="pw" truststore-url="file:${jboss.server.config.dir}/gfi.jks" client-auth="true"/>
> </security-domain>
> <security-domain name="secured-app-domain">
> <authentication>
> <login-module code="Certificate" flag="required">
> <module-option name="securityDomain" value="trust-domain"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> {code}
> This configuration should work based on this article [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...] but the configuration is completely ignored and I have access to my application without any certificates imported to my browser. Can anyone explain this behaviour it just does not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6999) client authentication not behaving correctly?
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6999?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-6999.
------------------------------------
Resolution: Done
For questions like this please make use of the user forums to discuss what you are trying to achieve: -
http://wildfly.org/gethelp/
> client authentication not behaving correctly?
> ---------------------------------------------
>
> Key: WFLY-6999
> URL: https://issues.jboss.org/browse/WFLY-6999
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.2.Final
> Environment: Windows 7 with Java 8_91 and Wildfly 9.0.2
> Reporter: Pascal Knüppel
> Assignee: Darran Lofthouse
>
> I am currently reading the wildfly 9 documentation and I started to test some things and I began with client certificate authentication since I am going to need this feature in short future.
> I found a way to realize mutual authentication but this one is rather a workaround than anything else.
> For starters it is my intention to deploy a web application on an https-port that requires client authentication. Additionally I want other applications under the same port that do not require client authentication. This is a feature that does not seem to be possible eventhough the documentation uses references to the security-domain section here.
> Now I will provide my configuration how I configured my application and my wildfly server to activate client cert authentication. Note that I had to configure a second virtual host with a new port to accomplish this.
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <!--<login-config>-->
> <!--<auth-method>CLIENT-CERT</auth-method>-->
> <!--<!–<realm-name>secured-app-domain</realm-name>–>-->
> <!--</login-config>-->
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <server-instance>client-auth-server</server-instance>
> <virtual-host>client-auth-host</virtual-host>
> <!--<security-domain>secured-app-domain</security-domain>-->
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw" />
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="gfi"/>
> </authentication>
> </security-realm>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="client-auth-server">
> <https-listener name="secured-https" socket-binding="client-auth-https" security-realm="SSLRealm" verify-client="REQUIRED"/>
> <host name="client-auth-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> <socket-binding name="client-auth-https" port="${jboss.https.port:8444}"/>
> {code}
> This is everything needed for client-authentication if roles are not necessary. In case of using roles I had to add the uncommented security-domain not listed in the above code.
> Now to the point:
> this configuration seems undesirable to me and I am not sure if this is really wanted like this... as you can see in *web.xml* the tag <login-config> is uncommented. This configuration is completely ignored if set. The tag <realm-name> seems to have no effect either. I can write in this field what I want it changes nothing. So I did some more research and figured that the actual correct settings should be set like this:
> *web.xml*
> {code:xml}
> <security-constraint>
> <display-name>secure</display-name>
> <web-resource-collection>
> <web-resource-name>test</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <description>Die Kommunikation soll ausschließlich über HTTPS stattfinden.</description>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
> <login-config>
> <!-- Es wird erwartet, dass der Client sich mittels X509-Zertifikat dem Server gegenüber authentifiziert. -->
> <auth-method>CLIENT-CERT</auth-method>
> <!--<realm-name>secured-app-domain</realm-name> NO IDEA WHAT THIS SHOULD ACCOMPLISH -->
> </login-config>
> {code}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>secured-app-domain</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> ...
> <security-realm name="SSLRealm">
> <server-identities>
> <ssl>
> <keystore path="gfi.jks" relative-to="jboss.server.config.dir" keystore-password="pw"/>
> </ssl>
> </server-identities>
> </security-realm>
> ...
> <security-domain name="trust-domain">
> <jsse truststore-password="pw" truststore-url="file:${jboss.server.config.dir}/gfi.jks" client-auth="true"/>
> </security-domain>
> <security-domain name="secured-app-domain">
> <authentication>
> <login-module code="Certificate" flag="required">
> <module-option name="securityDomain" value="trust-domain"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> <https-listener name="tls" socket-binding="https" security-realm="SSLRealm"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> ...
> {code}
> This configuration should work based on this article [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...] but the configuration is completely ignored and I have access to my application without any certificates imported to my browser. Can anyone explain this behaviour it just does not seem correct to me.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months