[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on StartException in service start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7743:
-----------------------------
Description:
Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
{code:java}
15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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)
{code}
*Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem.
was:
Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
{code:java}
15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
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)
{code}
> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
> *Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on StartException in service start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7743:
--------------------------------
Assignee: (was: Jan Kalina)
> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
> *Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on StartException in service start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7743:
-----------------------------
Summary: Infinite wildfly boot on StartException in service start (was: Infinite wildfly boot on properties-realm start exception)
> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7741) JUnit Assumptions with assume are broken in arq testcase for @BeforeClass and @AfterClass
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-7741?page=com.atlassian.jira.plugin.... ]
Chao Wang resolved WFLY-7741.
-----------------------------
Assignee: Chao Wang
Resolution: Rejected
The problem here is that it can not use assumption in @AfterClass method.
Only in @BeforeClass method is acceptable behavior
> JUnit Assumptions with assume are broken in arq testcase for @BeforeClass and @AfterClass
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-7741
> URL: https://issues.jboss.org/browse/WFLY-7741
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> 1. Write a simple unit test with JUnit assumptions in @BeforeClass and @AfterClass methods.
> {code:java}
> @RunWith(Arquillian.class)
> public class ArqAssumeInBeforeClassTestCase {
> @BeforeClass
> public static void beforeClass() throws IOException, InterruptedException {
> Assume.assumeTrue(false); // this should skip
> }
> @AfterClass
> public static void afterClass() throws IOException {
> Assume.assumeTrue(false); // this should skip
> }
> @Test
> public void test() {
> }
> }
> {code}
> 2. Inside wildfly/testsuite run command:
> mvn clean install -Dts.noSmoke -Dts.basic -Dtest=ArqAssumeInBeforeClassTestCase (for example in basic ts)
> 3. You will see the AssumptionViolatedException from @BeforeClass and @AfterClass methods as:
> {noformat}
> T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.006 sec <<< FAILURE! - in org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase Time elapsed: 0.005 sec <<< ERROR!
> org.junit.AssumptionViolatedException: got: <false>, expected: is <true>
> at org.junit.Assume.assumeThat(Assume.java:95)
> at org.junit.Assume.assumeTrue(Assume.java:41)
> at org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.beforeClass(ArqAssumeInBeforeClassTestCase.java:17)
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase Time elapsed: 0.006 sec <<< ERROR!
> org.junit.AssumptionViolatedException: got: <false>, expected: is <true>
> at org.junit.Assume.assumeThat(Assume.java:95)
> at org.junit.Assume.assumeTrue(Assume.java:41)
> at org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.afterClass(ArqAssumeInBeforeClassTestCase.java:22)
> Results :
> Tests in error:
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> Run 1: ArqAssumeInBeforeClassTestCase.beforeClass:17 » AssumptionViolated got: <false...
> Run 2: ArqAssumeInBeforeClassTestCase.afterClass:22 » AssumptionViolated got: <false>...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> {noformat}
> However, the executions inside @BeforeClass and @AfterClass methods should simply be skipped.
> Example test https://github.com/soul2zimate/wildfly/commits/ArqAssumeInBeforeClassTest...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-7742:
-----------------------------------
KeyStores are case-insensitive, so credential stores backed by KeyStores must also be (unless we do some kind of encoding scheme).
I think we should unify on mapping to lowercase by way of the {{ROOT}} locale.
> CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2088:
--------------------------------------------
Summary: Enhance CLI to support Aesh Commands
Key: WFCORE-2088
URL: https://issues.jboss.org/browse/WFCORE-2088
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
This is the CLI.next project.
Aesh 1.0 will come with a Command API based on annotations. It makes full sense to redesign part of the existing commands, still offering backward compatibility using this API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7742:
-------------------------------
Summary: CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase. (was: CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.)
> CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on properties-realm start exception
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7743:
-----------------------------
Affects Version/s: 10.1.0.Final
(was: 11.0.0.Alpha1)
> Infinite wildfly boot on properties-realm start exception
> ---------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7742:
-------------------------------
Description:
CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
{code}
In csfile001.jceks you can see only "csname001" entry.
*There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
{code}
/subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
{code}
And now you can use both (csFF and csff) as CredStoreRef alias
e.g.
{code}
/subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
{code}
Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
*NOTE*
https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
{code}
Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
{code}
*Suggestions for solution*
* We must unite case (in)sensitive between CS keystore file and CS in memory
* implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
* something else
was:
CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
{code}
In csfile001.jceks you can see only "csname001" entry.
*What is the biggest problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.*
*NOTE*
https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
{code}
Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
{code}
*Suggestions for solution*
* implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
* add NOTE to documentation
* something else
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months