May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1712) Enhanced Audit Logging - RFC support and reliability/speed customization

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1712?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1712: ---------------------------- Fix Version/s: 1.10.0.CR1 > Enhanced Audit Logging - RFC support and reliability/speed customization > ------------------------------------------------------------------------ > > Key: ELY-1712 > URL: https://issues.jboss.org/browse/ELY-1712 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Assignee: Justin Cook > Priority: Major > Fix For: 1.10.0.CR1 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for: > * RFC5424 Support > * RFC3164 Support > * Reliability vs Speed Customization -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4447) Elytron: Ability to load the attributes of an identity from multiple sources

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4447?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4447: ------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 9.0.0.CR1) > Elytron: Ability to load the attributes of an identity from multiple sources > ---------------------------------------------------------------------------- > > Key: WFCORE-4447 > URL: https://issues.jboss.org/browse/WFCORE-4447 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 10.0.0.Beta1 > > > In previous versions a {{security-domain}} was used to merge or add roles from multiple repositories. For example the roles for the users were obtained from two different ldaps and a database. All the roles were merged and the final authenticated principal belonged to all of them. The old picketbox subsystem used stacking of login modules (and password) to implement this feature. This use-case is not rare among the customers. > This issue is avoiding migrations from the old security subsystem to elytron. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-3947: ------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 9.0.0.CR1) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Major > Fix For: 10.0.0.Beta1 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4227) Add the ability for the CLI SSL security commands to be able to obtain a server certificate from Let's Encrypt

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4227?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4227: ------------------------------- Fix Version/s: 10.0.0.Beta1 > Add the ability for the CLI SSL security commands to be able to obtain a server certificate from Let's Encrypt > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4227 > URL: https://issues.jboss.org/browse/WFCORE-4227 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Marek Marusic > Assignee: Marek Marusic > Priority: Major > Fix For: 10.0.0.Beta1 > > > WFCORE-3447 introduced high-level security commands (ssl enable-ssl-management and ssl enable-ssl-http-server) for enabling one-way and two-way SSL easily. To generate the server certificate, these high-level security commands made use of key-store management operations to generate a self-signed certificate. Since it is now possible to obtain certificates from the Let's Encrypt certificate authority using the CLI, the high-level security commands should be updated so that in addition to being able to generate a self-signed server certificate, they can also obtain a server certificate from Let's Encrypt. Details on the new management operations for obtaining and managing certificates from Let's Encrypt can be found in the analysis document and in this blog post. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4362) Make the certificate authority used by a certificate-authority-account configurable

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4362?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4362: ------------------------------- Fix Version/s: 10.0.0.Beta1 > Make the certificate authority used by a certificate-authority-account configurable > ----------------------------------------------------------------------------------- > > Key: WFCORE-4362 > URL: https://issues.jboss.org/browse/WFCORE-4362 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 10.0.0.Beta1 > > > Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a {{certificate-authority-account}}. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12044) Make the certificate authority used by a certificate-authority-account configurable

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFLY-12044?page=com.atlassian.jira.plugin... ] Farah Juma updated WFLY-12044: ------------------------------ Fix Version/s: 18.0.0.Beta1 > Make the certificate authority used by a certificate-authority-account configurable > ----------------------------------------------------------------------------------- > > Key: WFLY-12044 > URL: https://issues.jboss.org/browse/WFLY-12044 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 18.0.0.Beta1 > > > Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a certificate-authority-account. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on WFLY-12090: --------------------------------------- There is actually another bug, this one only reproduced when the remote server no longer has the resource and, hence, provides no Xids for the resource being recovered: WFTC-64. I'm also submitting a fix for this. > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on WFLY-12090: --------------------------------------- [~ochaloup] I correct myself. After investigating, I can see that the not cleaning log files occurs everytime the server restarts, i.e., WFTC-62 is the cause of the problem here. Hence, differently than I first thought, the behavior I'm observing with the logs not being deleted has nothing to do with the fact that there is no EJB to perform recovery on the other side of the server. I'll link WFTC-62 to this Jira as well, since we have now a simpler reproducer than using OpenShift, and I'll submit a PR. > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.sy... ] Farah Juma reassigned ELY-613: ------------------------------ Assignee: Ashley Abdel-Sayed > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: static_analysis > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12114) Ability to configure configure an EJB to not be pooled

by Brad Maxwell (Jira)

[ https://issues.jboss.org/browse/WFLY-12114?page=com.atlassian.jira.plugin... ] Brad Maxwell commented on WFLY-12114: ------------------------------------- Workaround is change the default of slsb-strict-max-pool by removing the bean-instance-pool-ref to make the default instance on demand. Then for all EJBs that need to be pooled add @Pool or jboss-ejb3.xml and specify them to use slsb-strict-max-pool or other configuration. {code} <stateless> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> </stateless> {code} > Ability to configure configure an EJB to not be pooled > ------------------------------------------------------ > > Key: WFLY-12114 > URL: https://issues.jboss.org/browse/WFLY-12114 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Brad Maxwell > Assignee: Cheng Fang > Priority: Minor > > Ability to configure configure an EJB to not be pooled > Currently SLSB/MDB's by default use the strict-max-pool configuration and an EJB can use @Pool or jboss-ejb3.xml to specify that a particular EJB use a different pool configuration. > If the default pool configuration is removed, for example, removing the bean-instance-pool-ref in the ejb3 subsystem from the stateless, would change the default pool configuration use to be none. Then the default for all EJBs is to create an EJB instance on demand when needed and destroy it when done. And then particular EJBs could then use @Pool or jboss-ejb3.xml to specify a pool configuration to use if instance on demand is not wanted. > It would be good if there was a way to configure the reverse, where in there is a default pool configuration for the EJBs and then a particular EJB could use @Pool or jboss-ejb3.xml to specify instance on demand. > {code} > <stateless> > <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> > </stateless> > {code} > Currently it does not look like there is a way to create a configuration that is instance on demand and strict-max-bean-instance-pool does not allow a max-pool-size of 0. > {code} > /subsystem=ejb3/strict-max-bean-instance-pool=nopool:add(max-pool-size=0) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-pool-size. A minimum value of 1 is required", > "rolled-back" => true > } > {code} > So if we had a way to create a pool config where it is instance-on-demand such to indicate there is no pool, then user could use @Pool or jboss-ejb3.xml to use the no-pool. Since there are not really any config for the instance-on-demand, it could just be a constant config, though it is nice when the standalone.xml shows options that are available. > /subsystem=ejb3/instance-on-demand-bean-instance-pool=no-pool:add() -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 May 2019