April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2433) Autocomplete doesn't work properly in credential-reference.store attribute.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2433?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2433: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Autocomplete doesn't work properly in credential-reference.store attribute. > --------------------------------------------------------------------------- > > Key: WFCORE-2433 > URL: https://issues.jboss.org/browse/WFCORE-2433 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta15 > > > Autocomplete doesn't work properly in credential-reference attribute. > I want to use autocomplete for credential-reference.store but it doesn't work. > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs1:add(uri="cr-store://test/cs1.jceks", credential-reference={store=<TAB> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2317) Nested attributes are not validated

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2317: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Nested attributes are not validated > ----------------------------------- > > Key: WFCORE-2317 > URL: https://issues.jboss.org/browse/WFCORE-2317 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha25 > Reporter: Michal Petrov > Assignee: Michal Petrov > Fix For: 3.0.0.Beta15 > > > Attributes of type Object do not have their inner attributes validated for e.g. "requires" and "alternatives". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2267: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta15 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2136: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta15 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2101: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta15 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2633) Allow specification of "non-sensitive" values on an AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2633?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2633: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Allow specification of "non-sensitive" values on an AttributeDefinition > ------------------------------------------------------------------------ > > Key: WFCORE-2633 > URL: https://issues.jboss.org/browse/WFCORE-2633 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta15 > > > The RBAC system requires the user to be in a role with permissions to perform "security sensitive" actions in order to manipulate "defined" attributes with a sensitivity constraint applied. And "defined" in this case includes attributes that are not explicitly configured by the user but which have default values. But for attributes without default values that are left undefined, the non-sensitive roles are allowed to perform that action. > The requirement here is to open this up such that certain "defined" values (explicitly configured or default) also are treated as non-sensitive. > See WFCORE-8521 for an explicit example of this. If the datasource subsystem "elytron-enabled" attribute has a value of "false", and other related attributes are left undefined, that basically means there is no configuration set up for how the DS should authenticate to the DB. Such a setup is likely useless (since the DB most likely requires authentication) but in and of itself doesn't involve anything security sensitive on the WildFly side, so configuring false shouldn't be sensitive. It's analogous to leaving other related attributes like "username" and "password" undefined which in previous releases was considered to be non-sensitive. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2589: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Affects Versions: 3.0.0.Beta11 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 3.0.0.Beta15 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2528) Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2528?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2528: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > Clean up testsuite Elytron registration -- VaultPasswordsInCLITestCase > ---------------------------------------------------------------------- > > Key: WFCORE-2528 > URL: https://issues.jboss.org/browse/WFCORE-2528 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta15 > > > Leftover cleanup from WFCORE-1958 since VaultPasswordsInCLITestCase is not enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2609) CLIRolloutPlanTestCase hang

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2609?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2609: ------------------------------------- Fix Version/s: 3.0.0.Beta15 (was: 3.0.0.Beta14) > CLIRolloutPlanTestCase hang > --------------------------- > > Key: WFCORE-2609 > URL: https://issues.jboss.org/browse/WFCORE-2609 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta15 > > > Hang: > https://ci.wildfly.org/viewLog.html?buildId=53176&buildTypeId=WF_MasterWi... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8542) StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY

by David Lloyd (JIRA)

David Lloyd created WFLY-8542: --------------------------------- Summary: StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY Key: WFLY-8542 URL: https://issues.jboss.org/browse/WFLY-8542 Project: WildFly Issue Type: Bug Components: EJB Reporter: David Lloyd It's not really clear what the correct behavior is, but it definitely isn't this: {noformat} 2017-04-07 14:53:09 javax.ejb.EJBTransactionRolledbackException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:160) 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257) 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:334) 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327) 2017-04-07 14:53:09 at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) 2017-04-07 14:53:09 at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:84) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256) 2017-04-07 14:53:09 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) 2017-04-07 14:53:09 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) 2017-04-07 14:53:09 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) 2017-04-07 14:53:09 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380) 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:457) 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:452) 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:164) 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 2017-04-07 14:53:09 at java.lang.Thread.run(Thread.java:745) 2017-04-07 14:53:09 Caused by: java.lang.IllegalStateException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:76) 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:78) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:118) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) 2017-04-07 14:53:09 at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59) 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240) 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255) 2017-04-07 14:53:09 ... 42 more {noformat} If the transaction is in ROLLBACK_ONLY, then any of these might possibly be correct behavior: * Reject the invocation with a specific exception explaining that the method cannot be invoked when the transaction is in ROLLBACK_ONLY (preferably with a spec citation) * Allow the invocation to proceed without registering the synchronization (this probably isn't correct but might be) * Allow the invocation to proceed and use a "backdoor" to register the user synchronization anyway -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017