[JBoss JIRA] (WFLY-8799) Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8799:
---------------------------------
Summary: Remoting connection sharing causes authentication failures - DIGEST SASL mechanism
Key: WFLY-8799
URL: https://issues.jboss.org/browse/WFLY-8799
Project: WildFly
Issue Type: Bug
Components: Remoting, Security
Reporter: Josef Cacek
Assignee: David Lloyd
Priority: Blocker
Server rejects DIGEST SASL authentication in some cases when an existing remoting connection is reused. It seems the protocol name is not updated or matched correctly. The root cause of the problem is moreover hidden due to JBEAP-10953.
Clients just get:
{noformat}
Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000304: Server rejected authentication
at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:340)
at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:178)
at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:478)
at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:467)
...
{noformat}
The hidden exception stack trace is:
{noformat}
javax.security.sasl.SaslException: ELY05088: [DIGEST-MD5] digest-uri "remote+http/doma" not accepted
at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:239)
at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
at org.jboss.remoting3.ConnectionImpl.lambda$receiveAuthResponse$3(ConnectionImpl.java:273)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
{noformat}
We hit this problem as an intermittent failure in the AS testsuite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6895:
--------------------------------------
Assignee: Brian Stansberry (was: Tomasz Adamski)
Resolution: Done
Resolving for 10.2 and 11.0, the former based on the linked PR (thanks!), the latter based on WFCORE-1272.
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Brian Stansberry
> Fix For: 10.2.0.Final, 11.0.0.Beta1
>
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2823) Patching is doing runtime work in Stage.MODEL
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2823:
----------------------------------------
Summary: Patching is doing runtime work in Stage.MODEL
Key: WFCORE-2823
URL: https://issues.jboss.org/browse/WFCORE-2823
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Patching
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The patching module OSHs do their work in the execute(....) method of the OSH registered with the ManagementResourceRegistration. This runs in Stage.MODEL which means the patching work is in MODEL even though it's not about the configuration model stuff that should be the only concern of Stage.MODEL.
Simple fix is to move the logic to an added Stage.RUNTIME step.
This is no big deal except it prevents the WFCORE-2816 fix that would allow the kernel to guard against improper behavior by subsystems.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (LOGMGR-157) Provide faster alternative to SimpleDataFormat
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-157?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-157:
--------------------------------------
We could consider a change to use the new {{java.time}} API however so far we've guaranteed the pattern can be any pattern understood by the {{SimpleDateFormat}}. This could potentially break compatibility, but may be worth consideration.
> Provide faster alternative to SimpleDataFormat
> ----------------------------------------------
>
> Key: LOGMGR-157
> URL: https://issues.jboss.org/browse/LOGMGR-157
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Affects Versions: 2.0.6.Final
> Reporter: Koen Janssens
> Attachments: DateFormatPerformance.java
>
>
> Whenever a data or timestamp is included in the logging pattern, SimpleDataFormat is used for formatting. Even with one instance per thread, it is still a heavy beast.
> Other logging libraries (like the 15 year old log4j) have 'fast tracks' for known formats such as ISO 8601. These implementations are faster and generate less memory garbage.
> During profiling, i discovered that simpledateformat is doing a lot of stuff while printing a date:
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.logmanager.handlers.AsyncHandler$AsyncTask.run(AsyncHandler.java:196)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:224)
> at org.jboss.logmanager.formatters.Formatters$5.renderRaw(Formatters.java:389)
> at java.text.DateFormat.format(DateFormat.java:345)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
> at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125)
> at java.util.Calendar.getDisplayName(Calendar.java:2110)
> at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:340)
> at java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:364)
> at sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85)
> at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:145)
> at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:710)
> at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:127)
> at sun.util.resources.LocaleData.getBundle(LocaleData.java:163)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:163)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:167)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:890)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1348)
> at java.util.ResourceBundle.checkList(ResourceBundle.java:1400)
> at java.util.Collections$UnmodifiableCollection.isEmpty(Collections.java:1031)
> at java.util.AbstractCollection.isEmpty(AbstractCollection.java:86)
> I have attached a small comparision between simpledateformat performance and log4j ISO formatting performance. It roughly a factor 10 'faster'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8798) CLI Opertation 'load' for Elytron key-store does not change key used by management
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8798?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved JBEAP-10975 to WFLY-8798:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8798 (was: JBEAP-10975)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> CLI Opertation 'load' for Elytron key-store does not change key used by management
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8798
> URL: https://issues.jboss.org/browse/WFLY-8798
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: management-model, ssl
>
> When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
> We request blocker flag since this issue blocks RFE EAP7-455.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8798) CLI Opertation 'load' for Elytron key-store does not change key used by management
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8798?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-8798:
-----------------------------
Labels: management-model ssl (was: KK-DR18 eap71_beta management-model ssl)
> CLI Opertation 'load' for Elytron key-store does not change key used by management
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8798
> URL: https://issues.jboss.org/browse/WFLY-8798
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: management-model, ssl
>
> When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
> We request blocker flag since this issue blocks RFE EAP7-455.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)
by Tom Arnold (JIRA)
[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ]
Tom Arnold commented on WFLY-6895:
----------------------------------
Thanks Brian!
> TimerService problem(duplicated resource)
> -----------------------------------------
>
> Key: WFLY-6895
> URL: https://issues.jboss.org/browse/WFLY-6895
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
> <simple-election-policy>
> <name-preferences>master</name-preferences>
> </simple-election-policy>
> </singleton-policy>
> {code}
> Reporter: Artur Kowalczyk
> Assignee: Tomasz Adamski
> Fix For: 10.2.0.Final, 11.0.0.Beta1
>
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)
> at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)
> at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1566) Unable to lookup Stateless KieSession and KieBase from Remote Java Client
by Dhamodharan Krishnan (JIRA)
Dhamodharan Krishnan created DROOLS-1566:
--------------------------------------------
Summary: Unable to lookup Stateless KieSession and KieBase from Remote Java Client
Key: DROOLS-1566
URL: https://issues.jboss.org/browse/DROOLS-1566
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.5.0.Final
Reporter: Dhamodharan Krishnan
Assignee: Edson Tirelli
The rules that I define in Stateful or the default KieSession and KieBase are picked up the Remote Java client. The rules that I define in Stateless KieSessions or KieBase are not picked up.
I am not able to define rules in Stateless Kie Session. And I get duplicate data as part of my response as the facts injected into the Working memory seems to get bundled.
For eg, if a response POJO is supposed to contain 3 inner objects as part of its Response.
Response.java
{
List<Person> personsList;
}
Lets assume that the response should contain 3 matching persons as part of its response.
But each time, I hit the Kie Container from the Remote Java client, the results get bundled and it goes in Arithmetic progression as
3 , 6, 9, 12, 15, .... and so on until I restart my KieServer instance itself.
Thats where I am not clear on how to configure the KieContainer to make sure the results are not bundled.
Imagine, if I am going to call the Kie Container from different instances, it may even be giving wrong results .
As it returns the stocked up data.
Hope you understand my problem.
Thats where I try to configure Stateless KieSession and map my package to that.
But the remote Java client is not able to pick the Stateless KieSession.
It picks only Stateful ones.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1165) Wildfly Elytron Tool, credential-store command "add" option doesn't contain entry-type in summary for adding new alias to credential store storage.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1165:
---------------------------------
Summary: Wildfly Elytron Tool, credential-store command "add" option doesn't contain entry-type in summary for adding new alias to credential store storage.
Key: ELY-1165
URL: https://issues.jboss.org/browse/ELY-1165
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Critical
Wildfly Elytron Tool credential-store command "add" option doesn't contain entry-type in summary for adding new alias to credential store storage.
When user uses non-default entry-type that is expected entry-type in CLI command as in example below:
{code}
/subsystem=elytron/credential-store=test/alias=secret_alias:add(secret-value="secret_password", entry-type="org.wildfly.security.credential.PasswordCredential")
{code}
*How to reproduce*
{code}
java -jar ./bin/wildfly-elytron-tool.jar credential-store --create --add secret_alias --password pass123 --secret secret_password --location store.jceks -n org.wildfly.security.credential.PasswordCredential --summary
Alias "secret_alias" has been successfully stored
Credential store command summary:
--------------------------------------
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="store.jceks",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="pass123"})
/subsystem=elytron/credential-store=test/alias=secret_alias:add(secret-value="secret_password")
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month