[JBoss JIRA] (WFCORE-2185) Require Maven 3.3.1+ and introduce mvnw
by Peter Palaga (JIRA)
Peter Palaga created WFCORE-2185:
------------------------------------
Summary: Require Maven 3.3.1+ and introduce mvnw
Key: WFCORE-2185
URL: https://issues.jboss.org/browse/WFCORE-2185
Project: WildFly Core
Issue Type: Task
Reporter: Peter Palaga
Assignee: Peter Palaga
Fix For: 3.0.0.Alpha18
There are three closely related things here:
* Maven 3.3.1+ is required by the Enforcer Plugin
* mvnw (a.k.a. Maven Wrapper) is a script that downloads and installs
(if necessary) the required Maven version to ~/.m2/wrapper and runs it
from there. "mvn -N io.takari:maven:wrapper" was used to create all the
necessary files. The same command can be used in the future to upgrade
to a newer wrapper version. Maven version used by the wrapper is stored
in .mvn/wrapper/maven-wrapper.properties
* .mvn/jvm.config is a place where Maven 3.3.1+ looks for JVM parameters
(memory, etc.) which were traditionally defined in the MAVEN_OPTS
environment variable.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7583) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFLY-7583?page=com.atlassian.jira.plugin.... ]
Michal Petrov commented on WFLY-7583:
-------------------------------------
[~brian.stansberry] unfortunately no, quotes turn it into a plain string.
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFLY-7583
> URL: https://issues.jboss.org/browse/WFLY-7583
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7879) JMS bridge not able to lookup remote destination
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7879?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-8230 to WFLY-7879:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7879 (was: JBEAP-8230)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR8)
(was: 7.1.0.DR10)
Affects Testing: (was: Regression)
> JMS bridge not able to lookup remote destination
> ------------------------------------------------
>
> Key: WFLY-7879
> URL: https://issues.jboss.org/browse/WFLY-7879
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> There is regression in EAP 7.1.0.DR8. JMS bridge is not able to lookup queue or connection factory from remote EAP 7.1.0.DR8 server.
> If server with JMS bridge is started then following warning is logged in server.log:
> {code}
> 13:30:14,006 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoClassDefFoundError: org/jboss/remoting3/Remoting]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:51) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:152) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) [rt.jar:1.8.0_71]
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.8.0_71]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) [rt.jar:1.8.0_71]
> at javax.naming.InitialContext.init(InitialContext.java:244) [rt.jar:1.8.0_71]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.8.0_71]
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:43) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747) [artemis-jms-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_71]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/remoting3/Remoting
> at org.jboss.naming.remote.client.EndpointCache.get(EndpointCache.java:47) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.naming.remote.client.InitialContextFactory.createEndpoint(InitialContextFactory.java:226) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateEndpoint(InitialContextFactory.java:207) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:170) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:146) [jboss-remote-naming-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
> ... 18 more
> {code}
> This seems to be related to upgrade remote-naming -> wildfly-naming. As JMS bridge is using "artemis" module the dependency for wildfly-naming should be updated.
> Configuration of JMS bridge:
> {code}
> <jms-bridge name="myBridge" module="org.apache.activemq.artemis" quality-of-service="ONCE_AND_ONLY_ONCE" failure-retry-interval="1000" max-retries="-1" max-batch-size="10" max-batch-time="100" add-messageID-in-header="true">
> <source connection-factory="java:/ConnectionFactory" destination="jms/queue/InQueue"/>
> <target connection-factory="jms/RemoteConnectionFactory" destination="jms/queue/OutQueue">
> <target-context>
> <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
> <property name="java.naming.provider.url" value="http-remoting://127.0.0.1:10080"/>
> </target-context>
> </target>
> </jms-bridge>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7878) Elytron security realms cannot be used only for authorization
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7878?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7878:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Elytron security realms cannot be used only for authorization
> -------------------------------------------------------------
>
> Key: WFLY-7878
> URL: https://issues.jboss.org/browse/WFLY-7878
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: print-roles.war
>
>
> Scenario: I try to configure application server for scenario when different identity stores are used for authentication and authorization (e.g. username/password are stored in LDAP and roles are assigned from Database).
> In case when authentication and authorization is handled by different security realms in Elytron (i.e. aggregate realm is used) then authorization works only in case, when identity store for realm used for authorization includes the username also for authentication. See Steps to Reproduce for more details.
> We request blocker since using different identity stores for authentication and authorization is common scenario which should be provided by Elytron. Even out documentation explicitly mentioned that scenarios [1]:
> ??Consider the case where users are managed in a central LDAP server and application-specific roles are stored in the application’s relational database.??
> I tried this scenario with Properties and Filesystem Realms for authentication and Properties and Ldap Realms for authorization.
> [1] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7878) Elytron security realms cannot be used only for authorization
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7878?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7878:
-------------------------------
Attachment: print-roles.war
> Elytron security realms cannot be used only for authorization
> -------------------------------------------------------------
>
> Key: WFLY-7878
> URL: https://issues.jboss.org/browse/WFLY-7878
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: print-roles.war
>
>
> Scenario: I try to configure application server for scenario when different identity stores are used for authentication and authorization (e.g. username/password are stored in LDAP and roles are assigned from Database).
> In case when authentication and authorization is handled by different security realms in Elytron (i.e. aggregate realm is used) then authorization works only in case, when identity store for realm used for authorization includes the username also for authentication. See Steps to Reproduce for more details.
> We request blocker since using different identity stores for authentication and authorization is common scenario which should be provided by Elytron. Even out documentation explicitly mentioned that scenarios [1]:
> ??Consider the case where users are managed in a central LDAP server and application-specific roles are stored in the application’s relational database.??
> I tried this scenario with Properties and Filesystem Realms for authentication and Properties and Ldap Realms for authorization.
> [1] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7878) Elytron security realms cannot be used only for authorization
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7878:
----------------------------------
Summary: Elytron security realms cannot be used only for authorization
Key: WFLY-7878
URL: https://issues.jboss.org/browse/WFLY-7878
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
Attachments: print-roles.war
Scenario: I try to configure application server for scenario when different identity stores are used for authentication and authorization (e.g. username/password are stored in LDAP and roles are assigned from Database).
In case when authentication and authorization is handled by different security realms in Elytron (i.e. aggregate realm is used) then authorization works only in case, when identity store for realm used for authorization includes the username also for authentication. See Steps to Reproduce for more details.
We request blocker since using different identity stores for authentication and authorization is common scenario which should be provided by Elytron. Even out documentation explicitly mentioned that scenarios [1]:
??Consider the case where users are managed in a central LDAP server and application-specific roles are stored in the application’s relational database.??
I tried this scenario with Properties and Filesystem Realms for authentication and Properties and Ldap Realms for authorization.
[1] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2183) ParallelBootOperation context isn't updating the parent context in setRollbackOnly()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2183?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2183:
------------------------------------------
This was observed when looking into issues related to WFCORE-2182. The SecurityException incorrectly thrown due to the 2182 issue resulted in the subsystem rolling back, but the server didn't abort. In a way not aborting is good since the failure shouldn't have triggered rollback but still the rollback handling was wrong.
> ParallelBootOperation context isn't updating the parent context in setRollbackOnly()
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2183
> URL: https://issues.jboss.org/browse/WFCORE-2183
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> If an subsystem handler calls OperationContext.setRollbackOnly() during boot, only the ParallelBootOperationContext handling that subsystem is effected. The result is that subsystem rolls back but the boot itself is not aborted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2182) RuntimeVaultReader should not throw SecurityException
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2182:
----------------------------------------
Summary: RuntimeVaultReader should not throw SecurityException
Key: WFCORE-2182
URL: https://issues.jboss.org/browse/WFCORE-2182
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
RuntimeVaultReader is throwing SecurityException if it catches a SecurityVaultException from PicketBoxSecurityVault. But the causes of those SecurityVaultException are not really security breaches, they just reflect failed searches, or, less likely, incorrect vault setup.
Converting these into SecurityException, which is a RuntimeException, means the vault lookup will fail the management op that triggered it in a way that overrides rollback-on-runtime-failure=false. But at least in the case of failed searches, this is no different than any other failed attempt to resolve an expression and should be treated as such.
Perhaps the type of the getCause() value from the SecurityVaultException can be used to discriminate behavior between failed searches and other issues, or perhaps the distinction can be ignored.
Here is an example of a failed search using EAP 6:
{code}
12:46:34,830 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 27) JBAS014612: Operation ("enable") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "xyzDS")
]): java.lang.SecurityException: JBAS013311: Security Exception
at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:115)
at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45)
at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionString(ExpressionResolverImpl.java:319) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ExpressionResolverImpl.parseAndResolve(ExpressionResolverImpl.java:228) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionStringRecursively(ExpressionResolverImpl.java:130) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:72) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:54) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:782) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:1002) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ParallelBootOperationContext.resolveExpressions(ParallelBootOperationContext.java:351) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AttributeDefinition$1.resolveExpressions(AttributeDefinition.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AttributeDefinition.resolveValue(AttributeDefinition.java:402) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:361) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:335) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.connector.util.ModelNodeUtil.getResolvedStringIfSetOrGetDefault(ModelNodeUtil.java:33)
at org.jboss.as.connector.subsystems.datasources.DataSourceModelNodeUtil.from(DataSourceModelNodeUtil.java:151)
at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:183)
at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:102)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:708) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:543) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.IllegalArgumentException: Null input buffer
at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:297)
at org.jboss.as.security.vault.RuntimeVaultReader.getValue(RuntimeVaultReader.java:141)
at org.jboss.as.security.vault.RuntimeVaultReader.getValueAsString(RuntimeVaultReader.java:123)
at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:113)
... 26 more
Caused by: java.lang.IllegalArgumentException: Null input buffer
at javax.crypto.Cipher.doFinal(Cipher.java:2161) [jce.jar:1.8.0_111]
at org.picketbox.util.EncryptionUtil.decrypt(EncryptionUtil.java:134)
at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:293)
...
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months