[JBoss JIRA] (WFLY-9128) Upgrade Apache CXF to 3.1.13
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.... ]
Ivo Studensky moved JBEAP-12338 to WFLY-9128:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9128 (was: JBEAP-12338)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web Services
(was: Web Services)
Target Release: (was: 7.1.0.GA)
> Upgrade Apache CXF to 3.1.13
> ----------------------------
>
> Key: WFLY-9128
> URL: https://issues.jboss.org/browse/WFLY-9128
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web Services
> Reporter: Ivo Studensky
> Assignee: Alessio Soldano
>
> Upgrade Apache CXF to 3.1.11 (from 3.1.10)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1309) Channel binding callback cannot support tls-unique
by David Lloyd (JIRA)
David Lloyd created ELY-1309:
--------------------------------
Summary: Channel binding callback cannot support tls-unique
Key: ELY-1309
URL: https://issues.jboss.org/browse/ELY-1309
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI, Authentication Client, Authentication Server, Callbacks, SASL
Reporter: David Lloyd
Assignee: David Lloyd
Priority: Blocker
The revised API for the channel binding callback uses SSL sessions, but the standard TLS channel binding types [according to the RFC|https://tools.ietf.org/html/rfc5929] are associated with the connection, not the session. It is likely that the proposed channel bindings JDK API will exist on SSLSocket/SSLEngine. Introduce an API that allows the callback handlers to acquire the connection information using a forward-compatible API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JGRP-2199) JDBC_PING cluster doesn't handle shutdown members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2199?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2199:
--------------------------------
OK, installed Postgresql and the JDBC driver. The configuration needed a bit of tweaking, e.g. VARBINARY is not supported:
{code:xml}
<JDBC_PING
...
initialize_sql="CREATE TABLE jgroups_discover (own_addr varchar(200) NOT NULL, cluster_name
varchar(200) NOT NULL, ping_data bytea DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) );"
insert_single_sql="INSERT INTO jgroups_discover (own_addr, cluster_name, ping_data) VALUES (?, ?, ?)"
delete_single_sql="DELETE FROM jgroups_discover WHERE own_addr = ? AND cluster_name = ?"
clear_sql="DELETE FROM jgroups_discover WHERE cluster_name = ?"
select_all_pingdata_sql="SELECT ping_data, own_addr, cluster_name FROM jgroups_discover WHERE cluster_name = ?"
contains_sql="SELECT count(*) AS RECORDCOUNT FROM jgroups_discover WHERE cluster_name = ? AND own_addr = ?"
/>
{code}
> JDBC_PING cluster doesn't handle shutdown members
> -------------------------------------------------
>
> Key: JGRP-2199
> URL: https://issues.jboss.org/browse/JGRP-2199
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Douglas Adams
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: file-ping.xml, jdbc-ping.xml, stuck_starting_up.log
>
>
> FILE_PING and JDBC_PING have different behavior when a cluster's coordinator stops.
> With FILE_PING the coordinator will delete the whole cluster's file on shutdown of the coordinator.
> JDBC_PING does not do this and reveals a problematic flaw in how node's are handled on shutdown.
> When I added my own logging to the source of these files I observed that they're both continuously writing to the database/file all of the members because {{write()}} is called very frequently.
> ---
> Current behavior:
> GIVEN a cluster of JDBC_PING registered nodes
> WHEN a node shuts down
> THEN it removes itself from the database table AND the coordinator almost immediately re-adds the shut down member to the table because of the {{List<PingData>}} sent to write()
> GIVEN a cluster of JDBC_PING registered nodes has only the coordinator left
> WHEN the coordinator shuts down
> THEN the coordinator removes itself from the database and because there's no coordinator left the database shows a list of only the 'members' with no coordinator
> GIVEN a cluster of JDBC_PING registered nodes
> WHEN the coordinator shuts down or crashes and does not have time to remove itself from the database
> THEN the next node to start will never finish negotiating membership with the cluster because a phantom coordinator still exists (see attachement: stuck_starting_up.log)
> ---
> I expected the behavior between JDBC_PING and FILE_PING to remain consistent
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1307) For CachedIdentityAuthorizeCallback verify call to authorize succeeded
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1307?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse resolved ELY-1307.
-----------------------------------
Resolution: Done
> For CachedIdentityAuthorizeCallback verify call to authorize succeeded
> ----------------------------------------------------------------------
>
> Key: ELY-1307
> URL: https://issues.jboss.org/browse/ELY-1307
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.CR4
>
>
> {noformat}
> java.lang.IllegalStateException: ELY01003: No authentication is in progress
> at org.wildfly.security.auth.server.ServerAuthenticationContext$State.getAuthorizedIdentity(ServerAuthenticationContext.java:1186)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.getAuthorizedIdentity(ServerAuthenticationContext.java:334)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1084)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:231)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:174)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1307) For CachedIdentityAuthorizeCallback verify call to authorize succeeded
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1307?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1307:
----------------------------------
Description:
{noformat}
java.lang.IllegalStateException: ELY01003: No authentication is in progress
at org.wildfly.security.auth.server.ServerAuthenticationContext$State.getAuthorizedIdentity(ServerAuthenticationContext.java:1186)
at org.wildfly.security.auth.server.ServerAuthenticationContext.getAuthorizedIdentity(ServerAuthenticationContext.java:334)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1084)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:231)
at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:174)
{noformat}
> For CachedIdentityAuthorizeCallback verify call to authorize succeeded
> ----------------------------------------------------------------------
>
> Key: ELY-1307
> URL: https://issues.jboss.org/browse/ELY-1307
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.CR4
>
>
> {noformat}
> java.lang.IllegalStateException: ELY01003: No authentication is in progress
> at org.wildfly.security.auth.server.ServerAuthenticationContext$State.getAuthorizedIdentity(ServerAuthenticationContext.java:1186)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.getAuthorizedIdentity(ServerAuthenticationContext.java:334)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1084)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.authorize(FormAuthenticationMechanism.java:231)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:174)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1308) Alias from dependent credential store is not avalaible on server start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1308?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1308:
----------------------------
Description:
BouncyCastle external CredentialStore fail to store secret:
{code}
KeyStoreCredentialStore: flushing failed: java.lang.NullPointerException
at org.bouncycastle.jcajce.provider.BaseCipher.engineGetParameters(Unknown Source)
at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1020)
at javax.crypto.Cipher.init(Cipher.java:1245)
at javax.crypto.Cipher.init(Cipher.java:1186)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.saveSecretKey(KeyStoreCredentialStore.java:1299)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.store(KeyStoreCredentialStore.java:1283)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.flush(KeyStoreCredentialStore.java:779)
at org.wildfly.security.credential.store.CredentialStore.flush(CredentialStore.java:364)
at org.wildfly.extension.elytron.CredentialStoreResourceDefinition.storeSecret(CredentialStoreResourceDefinition.java:517)
{code}
was:
Testing BouncyCastle external store. Intermittently (25% in lab, 0% locally) it happens alias from dependent credential store is not avalaible on server start.
{code}
15:17:33,317 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:921)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:930)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:821)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:213)
at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
... 5 more
Caused by: java.security.KeyStoreException: BCFKS not found
at java.security.KeyStore.getInstance(KeyStore.java:851)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:919)
... 10 more
Caused by: java.security.NoSuchAlgorithmException: BCFKS KeyStore not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
at java.security.Security.getImpl(Security.java:695)
at java.security.KeyStore.getInstance(KeyStore.java:848)
... 11 more
{code}
Could that be problem of "late" required service start?
Although, I don't see similar problem with default JKES credential store, neither PKCS11 external credential store. PKCS11 store is however special case, because is loaded once per jvm.
Could that be problem of external credential store with file based keystore?
[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
> Alias from dependent credential store is not avalaible on server start
> ----------------------------------------------------------------------
>
> Key: ELY-1308
> URL: https://issues.jboss.org/browse/ELY-1308
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.CR2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> BouncyCastle external CredentialStore fail to store secret:
> {code}
> KeyStoreCredentialStore: flushing failed: java.lang.NullPointerException
> at org.bouncycastle.jcajce.provider.BaseCipher.engineGetParameters(Unknown Source)
> at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1020)
> at javax.crypto.Cipher.init(Cipher.java:1245)
> at javax.crypto.Cipher.init(Cipher.java:1186)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.saveSecretKey(KeyStoreCredentialStore.java:1299)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore$ExternalStorage.store(KeyStoreCredentialStore.java:1283)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.flush(KeyStoreCredentialStore.java:779)
> at org.wildfly.security.credential.store.CredentialStore.flush(CredentialStore.java:364)
> at org.wildfly.extension.elytron.CredentialStoreResourceDefinition.storeSecret(CredentialStoreResourceDefinition.java:517)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1308) Alias from dependent credential store is not avalaible on server start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1308?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-12335 to ELY-1308:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1308 (was: JBEAP-12335)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Credential Store
(was: Security)
Affects Version/s: 1.1.0.CR2
(was: 7.1.0.ER1)
> Alias from dependent credential store is not avalaible on server start
> ----------------------------------------------------------------------
>
> Key: ELY-1308
> URL: https://issues.jboss.org/browse/ELY-1308
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.CR2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Testing BouncyCastle external store. Intermittently (25% in lab, 0% locally) it happens alias from dependent credential store is not avalaible on server start.
> {code}
> 15:17:33,317 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:921)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:930)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:821)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:213)
> at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> ... 5 more
> Caused by: java.security.KeyStoreException: BCFKS not found
> at java.security.KeyStore.getInstance(KeyStore.java:851)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.getKeyStoreInstance(KeyStoreCredentialStore.java:919)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: BCFKS KeyStore not available
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
> at java.security.Security.getImpl(Security.java:695)
> at java.security.KeyStore.getInstance(KeyStore.java:848)
> ... 11 more
> {code}
> Could that be problem of "late" required service start?
> Although, I don't see similar problem with default JKES credential store, neither PKCS11 external credential store. PKCS11 store is however special case, because is loaded once per jvm.
> Could that be problem of external credential store with file based keystore?
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months