January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1904) Usage of vault for system-properties throws java.lang.SecurityException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1904: ----------------------------------------------- Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1174871|https://bugzilla.redhat.com/show_bug.cgi?id=1174871] from ON_QA to ASSIGNED > Usage of vault for system-properties throws java.lang.SecurityException > ----------------------------------------------------------------------- > > Key: WFLY-1904 > URL: https://issues.jboss.org/browse/WFLY-1904 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Beta1 > Reporter: Navin Surtani > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Steps to Reproduce: 1. add the lines in standalone.xml:- > {code} > <system-properties> > <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/> > <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" /> > </system-properties> > <vault> > <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/> > <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/> > <vault-option name="KEYSTORE_ALIAS" value="myalias"/> > <vault-option name="SALT" value="12345678"/> > <vault-option name="ITERATION_COUNT" value="44"/> > <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/> > </vault> > {code} > 2. start EAP6 in standalone mode > project_key: JBPAPP6 > Usage of vault for system-properties throws java.lang.SecurityException. > boot.log:- > {code} > 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-871) AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-871?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-871: -------------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 1174871|https://bugzilla.redhat.com/show_bug.cgi?id=1174871] from MODIFIED to ON_QA > AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault > ---------------------------------------------------------------------------- > > Key: SECURITY-871 > URL: https://issues.jboss.org/browse/SECURITY-871 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > > AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1904) Usage of vault for system-properties throws java.lang.SecurityException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1904: ----------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 1174871|https://bugzilla.redhat.com/show_bug.cgi?id=1174871] from MODIFIED to ON_QA > Usage of vault for system-properties throws java.lang.SecurityException > ----------------------------------------------------------------------- > > Key: WFLY-1904 > URL: https://issues.jboss.org/browse/WFLY-1904 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Beta1 > Reporter: Navin Surtani > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Steps to Reproduce: 1. add the lines in standalone.xml:- > {code} > <system-properties> > <property name="javax.net.ssl.trustStore" value="/dir/truststore.jks"/> > <property name="javax.net.ssl.trustStorePassword" value="${VAULT::blk::attr::MTBlYWUzNDEtMjI2MC00NWYzLWFiZmUtM2EyYjZkNDgyZWM4TElORV9CUkVBS215YWxpYXM=}" /> > </system-properties> > <vault> > <vault-option name="KEYSTORE_URL" value="/opt/jboss-eap-6.0/standalone/configuration/vault.jks"/> > <vault-option name="KEYSTORE_PASSWORD" value="MASK-2gTQPnrWJaqrh0pURMKAOw"/> > <vault-option name="KEYSTORE_ALIAS" value="myalias"/> > <vault-option name="SALT" value="12345678"/> > <vault-option name="ITERATION_COUNT" value="44"/> > <vault-option name="ENC_FILE_DIR" value="/opt/jboss-eap-6.0/standalone/configuration/"/> > </vault> > {code} > 2. start EAP6 in standalone mode > project_key: JBPAPP6 > Usage of vault for system-properties throws java.lang.SecurityException. > boot.log:- > {code} > 20:35:30,267 ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([("system-property" => "javax.net.ssl.trustStorePassword")]): java.lang.SecurityException: JBAS013322: Vault is not initialized > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:98) [jboss-as-security-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:58) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:40) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:455) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:689) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.operations.common.SystemPropertyAddHandler.execute(SystemPropertyAddHandler.java:112) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:175) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:191) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.ServerService.boot(ServerService.java:295) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.server.ServerService.boot(ServerService.java:270) [jboss-as-server-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:156) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1173492|https://bugzilla.redhat.com/show_bug.cgi?id=1173492] from ASSIGNED to MODIFIED > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1173493|https://bugzilla.redhat.com/show_bug.cgi?id=1173493] from ASSIGNED to MODIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4220) Subsystems in XML are in incorrect order

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-4220: ------------------------------------ Summary: Subsystems in XML are in incorrect order Key: WFLY-4220 URL: https://issues.jboss.org/browse/WFLY-4220 Project: WildFly Issue Type: Bug Components: Build System Reporter: Stuart Douglas Assignee: Stuart Douglas Priority: Blocker -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-4210: --------------------------------- Workaround Description: Add beans.xml to the application Workaround: Workaround Exists > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Stuart Douglas > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 55.0 Seconds > Post: 50 Seconds > Ajax: 7 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-4210: --------------------------------- Component/s: CDI / Weld JSF (was: Web (Undertow)) Issue is with how the JSF and CDI integration is performed > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Stuart Douglas > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 55.0 Seconds > Post: 50 Seconds > Ajax: 7 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-4210: ------------------------------------ Assignee: Stuart Douglas (was: Remy Maucherat) > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Stuart Douglas > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 55.0 Seconds > Post: 50 Seconds > Ajax: 7 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-490) ModelControllerImpl uses SecureRandom per request

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-490?page=com.atlassian.jira.plugin... ] Tomaz Cerar commented on WFCORE-490: ------------------------------------ Looking at the code it is not per request but once per boot of the server. > ModelControllerImpl uses SecureRandom per request > ------------------------------------------------- > > Key: WFCORE-490 > URL: https://issues.jboss.org/browse/WFCORE-490 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: James Livingston > Assignee: Brian Stansberry > > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... and https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... create a new SecureRandom which is used to seed a normal Random, and that is thrown away after one use. That causes it to use entropy from the OS pool, which if done at a sufficiently high rate on servers can cause stalls. > I can't think of any reason why the operation ID would need to be a secure random number rather than a normal one, so unless there is one it may be better to use a normal Random and not drain the entropy pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015