February 2019 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-11759) Use LegacyKernelServicesInitializer to exclude problematic resources from UndertowTransformersTestCase

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11759?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11759: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 16.0.0.Final) > Use LegacyKernelServicesInitializer to exclude problematic resources from UndertowTransformersTestCase > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-11759 > URL: https://issues.jboss.org/browse/WFLY-11759 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Minor > Fix For: 17.0.0.Beta1 > > > Revert this workaround using the exclusion feature added by WFCORE-4346: > https://github.com/wildfly/wildfly/pull/12098 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11569) Port EESecurityAuthMechanismTestCase to WildFly Elytron

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11569?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11569: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 16.0.0.Final) > Port EESecurityAuthMechanismTestCase to WildFly Elytron > ------------------------------------------------------- > > Key: WFLY-11569 > URL: https://issues.jboss.org/browse/WFLY-11569 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > Also ensure it passes with the security manager enabled. > Also see WFLY-11348 which is the failure with PicketBox. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11542) Update Undertow ApplicationSecurityDomain to use individual factories.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11542?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11542: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 16.0.0.Final) > Update Undertow ApplicationSecurityDomain to use individual factories. > ---------------------------------------------------------------------- > > Key: WFLY-11542 > URL: https://issues.jboss.org/browse/WFLY-11542 > Project: WildFly > Issue Type: Task > Components: Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > This is to move away from the deprecated 'org.wildfly.security.http.impl.ServerMechanismFactoryImpl' which will be removed soon as it was never public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11540) Update Maven dependencies to reference individual Elytron modules.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11540?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11540: ------------------------------------ Fix Version/s: 17.0.0.Beta1 (was: 16.0.0.Final) > Update Maven dependencies to reference individual Elytron modules. > ------------------------------------------------------------------ > > Key: WFLY-11540 > URL: https://issues.jboss.org/browse/WFLY-11540 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 17.0.0.Beta1 > > > This should also review the classes the application server users as we will likely want to start considering these public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019