[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Description:
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
was:
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.
To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Summary: Distributed shared web sessions can passivate prematurely (was: Distributed shared web sessions can expire prematurely)
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3458) External CS, PKCS11 can't be configured with externalPath
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugi... ]
Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:44 PM:
-----------------------------------------------------------------
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS, JCEKS and PKCS12), Elytron will throw exception.
was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: WFCORE-3458
> URL: https://issues.jboss.org/browse/WFCORE-3458
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 4.0.0.Alpha4
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) 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.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 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.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3458) External CS, PKCS11 can't be configured with externalPath
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugi... ]
Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:43 PM:
-----------------------------------------------------------------
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.
was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: WFCORE-3458
> URL: https://issues.jboss.org/browse/WFCORE-3458
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 4.0.0.Alpha4
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) 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.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> 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.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFLY-9632) Prep for tightened visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9632?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9632:
-----------------------------------
Summary: Prep for tightened visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields (was: Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields)
> Prep for tightened visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9632
> URL: https://issues.jboss.org/browse/WFLY-9632
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3478) Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3478?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3478:
-------------------------------------
Description: AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead. (was: AttributeDefinition and some subclasses in the controller module have some fields that are not private. This will make it problematic to evolve the management code in the future. Deprecate any that are protected, with a note to use the getter, and make package protected ones private.)
> Tighten visibility on some AttributeDefinition and AbstractAttributeDefinitionBuilder fields
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-3478
> URL: https://issues.jboss.org/browse/WFCORE-3478
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> AttributeDefinition and AbstractAttributeDefinitionBuilder in the controller module have some fields that are protected. This will make it problematic to evolve the management code in the future. Remove all direct use of these, switching to getters instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months