[Red Hat JIRA] (ELY-2081) Develop a simple properties based credential store for secret keys
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-2081:
-------------------------------------
Summary: Develop a simple properties based credential store for secret keys
Key: ELY-2081
URL: https://issues.redhat.com/browse/ELY-2081
Project: WildFly Elytron
Issue Type: Feature Request
Components: Credential Store
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.15.0.CR1
We need a simple solution in WildFly so that out out of the box we can support using an AES SecretKey to inline encrypt expressions in the management model such as password to other resources.
In the application server we end up in a "chicken and egg" situation as we always need a first key or secret to protect the attributes.
For this reason the credential store will not be protected by a password or encrypted, those could be added optionally later.
The application server integration may dynamically populate the credential store with a generated secret key if empty but that support is not needed in the store itself.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5272) Setting jacc provider to Elytron throws exceptions
by Bartosz Spyrko-Smietanko (Jira)
[ https://issues.redhat.com/browse/WFCORE-5272?page=com.atlassian.jira.plug... ]
Bartosz Spyrko-Smietanko moved JBEAP-20968 to WFCORE-5272:
----------------------------------------------------------
Component/s: Security
(was: Security)
Fix Version/s: (was: 7.3.7.GA)
Key: WFCORE-5272 (was: JBEAP-20968)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Project: WildFly Core (was: JBoss Enterprise Application Platform)
> Setting jacc provider to Elytron throws exceptions
> --------------------------------------------------
>
> Key: WFCORE-5272
> URL: https://issues.redhat.com/browse/WFCORE-5272
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Bartosz Spyrko-Smietanko
> Assignee: Bartosz Spyrko-Smietanko
> Priority: Major
>
> Performing:
> /subsystem=security:write-attribute(name=initialize-jacc, value=false)
> /subsystem=elytron/policy=jacc:add(jacc-policy={})
> reload
> Generates:
> -------------------------------------
> Operation: /subsystem=elytron/policy=jacc:add(jacc-policy={})
> Failure: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.policy" => "java
> .lang.RuntimeException: WFLYELY01024: Failed to register policy context handlers
> Caused by: java.lang.RuntimeException: WFLYELY01024: Failed to register policy
> context handlers
> Caused by: java.lang.IllegalStateException: WFLYELY01069: Invalid javax.securit
> y.jacc.PolicyConfigurationFactory loaded, expected org.wildfly.security.authz.jacc.
> ElytronPolicyConfigurationFactory but received org.jboss.security.jacc.JBossPolicyC
> onfigurationFactory."}}
> -------------------------------------
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-5271) NullPointerException creating new KeyStore without type
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-5271:
----------------------------------------
Summary: NullPointerException creating new KeyStore without type
Key: WFCORE-5271
URL: https://issues.redhat.com/browse/WFCORE-5271
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Darran Lofthouse
The "type" attribute when adding a new KeyStore has been made optional, this is so that is the KeyStore already exists we can dynamically discover the type.
If however the KeyStore does not exist this leads to a NullPointerException as it is never created:
{code:java}
/subsystem=elytron/key-store=test:add(relative-to=jboss.server.config.dir, path=test1.keystore, credential-reference={clear-text="${ENC:AAA}"})
{
"outcome" => "failed",
"failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.test" => "WF
LYELY00004: Unable to start the service.
Caused by: java.lang.NullPointerException"}},
"rolled-back" => true
} {code}
If it doesn't exist we should likely create it using the default from KeyStore.getDetaultType()
{code:java}
Caused by: java.lang.NullPointerExceptionCaused by: java.lang.NullPointerException at org.wildfly.extension.elytron@15.0.0.Beta1-SNAPSHOT//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:180) ... 8 more {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14403) Create test for to verify expressions are resolved correctly
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-14403?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-14403:
-------------------------------
Description:
This is a followup on JBEAP-20356.
In order to make sure there are no undetected problems of the kind described in JBEAP-20356, there should be a mechanism, which will allow for relatively simple testing of properties which have {{expression-allowed}} set to true.
Currently, the only known reliable way of testing this, is to write a runtime test per property/small set of properties. Since there are about 2000 properties which are currently set to be resolvable, this is not realistic.
was:
We need a mechanism that recursively read configuration model and set attributes that allow expression to an expression. Then challenge write operation and verify attribute is resolved to correct value.
The test shall be based on ExpressionSupportSmokeTestCase in domain TS
> Create test for to verify expressions are resolved correctly
> ------------------------------------------------------------
>
> Key: WFLY-14403
> URL: https://issues.redhat.com/browse/WFLY-14403
> Project: WildFly
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: Ivan Straka
> Assignee: Ivan Straka
> Priority: Critical
>
> This is a followup on JBEAP-20356.
> In order to make sure there are no undetected problems of the kind described in JBEAP-20356, there should be a mechanism, which will allow for relatively simple testing of properties which have {{expression-allowed}} set to true.
> Currently, the only known reliable way of testing this, is to write a runtime test per property/small set of properties. Since there are about 2000 properties which are currently set to be resolvable, this is not realistic.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14403) Create test for to verify expressions are resolved correctly
by Ivan Straka (Jira)
Ivan Straka created WFLY-14403:
----------------------------------
Summary: Create test for to verify expressions are resolved correctly
Key: WFLY-14403
URL: https://issues.redhat.com/browse/WFLY-14403
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: Ivan Straka
Assignee: Ivan Straka
We need a mechanism that recursively read configuration model and set attributes that allow expression to an expression. Then challenge write operation and verify attribute is resolved to correct value.
The test shall be based on ExpressionSupportSmokeTestCase in domain TS
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-6000) DMM Editor import generates invalid XML
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-6000:
--------------------------------------
Summary: DMM Editor import generates invalid XML
Key: DROOLS-6000
URL: https://issues.redhat.com/browse/DROOLS-6000
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.49.0.Final
Reporter: Matteo Mortari
Assignee: Guilherme Gomes
Attachments: base.dmn, importing.dmn
I created a simple base and importing DMN models.
The importing DMN model fails to validate XML due to the attributes starting with the column characters.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months