[JBoss JIRA] (WFLY-11073) Support hex encoding in jdbc-realm for elytron
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11073?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11073:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> Support hex encoding in jdbc-realm for elytron
> ----------------------------------------------
>
> Key: WFLY-11073
> URL: https://issues.jboss.org/browse/WFLY-11073
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation, Security
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: elytron
> Fix For: 17.0.0.Beta1
>
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (WFLY-11013) Hash encoding Exception when using @DatabaseIdentityStoreDefinition
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11013?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11013:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> Hash encoding Exception when using @DatabaseIdentityStoreDefinition
> -------------------------------------------------------------------
>
> Key: WFLY-11013
> URL: https://issues.jboss.org/browse/WFLY-11013
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 14.0.0.Final
> Environment: WildFly 14. Generic Linux. JDK 8/9
> Reporter: Francesco Marchioni
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 17.0.0.Beta1
>
> Attachments: javaee8-secure-servlet.zip
>
>
> When deploying one application using @DatabaseIdentityStoreDefinition, upon successful login, the following exception is thrown
> {code:java}
> java.lang.IllegalArgumentException: Bad hash encoding
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.decode(Pbkdf2PasswordHashImpl.java:209)
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.<init>(Pbkdf2PasswordHashImpl.java:191)
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl.verify(Pbkdf2PasswordHashImpl.java:147)
> at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:121)
> at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:101)
> at org.jboss.weldx.security.enterprise.identitystore.IdentityStore$635317201$Proxy$_$$_WeldClientProxy.validate(Unknown Source)
> at org.glassfish.soteria.cdi.DefaultIdentityStoreHandler.validate(DefaultIdentityStoreHandler.java:97)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (WFLY-11492) Quickstart http-custom-mechanism: documentation step fails
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11492?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11492:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> Quickstart http-custom-mechanism: documentation step fails
> ----------------------------------------------------------
>
> Key: WFLY-11492
> URL: https://issues.jboss.org/browse/WFLY-11492
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Reporter: Alan Hantke
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> Step #3, entitled *Configure the Application Security Domain* has the developer executing the following CLI command:
> {code:java}
> $ {jbossHomeName}/bin/jboss-cli.sh --connect --file=configure-security-domain.cli
> {code}
> However, this results in the following error:
> {code:java}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-1
> Operation: /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication)
> Failure: WFLYCTL0369: Required capabilities are not available:
> org.wildfly.security.http-authentication-factory.application-http-authentication; Possible registration points for this capability:
> /subsystem=elytron/http-authentication-factory=*
> {code}
> I am by no means an expert on this, but in looking at the standalone.xml file, I think that there needs to be a mate for the inserted *application-http-authentication*. I have attempted to continue without this changes installed by the CLI, but I am unable to execute the webapp even after providing the correct user/pass in the BASIC AUTH.
> I have verified that the same problem-causing syntax exists on the quickstart 'master', although I have been using branch '14.x' because neither 15.x nor 'master' would build when I execute 'mvn clean build'. Finally, the I encounter the problem with fresh installs of WildFly versions 10.1.0 and 14.0.
> Please change change the project if I have categorized the ticket incorrectly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (WFLY-11326) The org.jdom module should be removed
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11326?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11326:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> The org.jdom module should be removed
> -------------------------------------
>
> Key: WFLY-11326
> URL: https://issues.jboss.org/browse/WFLY-11326
> Project: WildFly
> Issue Type: Task
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> Follow up on WFLY-11325 by removing the module.
> I've assigned this to myself instead of just Unassigned to help increase the chances I remember to do it, but once WF 16 starts, if WFLY-11325 was resolved in 15, anyone should feel free to take this and do it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11489:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 17.0.0.Beta1
>
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11214:
------------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 16.0.0.Final)
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Fix For: 17.0.0.Beta1
>
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 8 months