[JBoss JIRA] (WFLY-8727) Resources that expose capabilities cannot use a capability reference for legacy security-domain attributes
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8727:
--------------------------------------
Summary: Resources that expose capabilities cannot use a capability reference for legacy security-domain attributes
Key: WFLY-8727
URL: https://issues.jboss.org/browse/WFLY-8727
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A number of resources expose 'security-domain' or similarly named attributes, the value of which is a legacy picketbox-based security domain. Referential integrity and value completion cannot be used for the attributes because the subsystem=security/security-domain resources do not expose a capability.
This also relates to WFLY-3858 which was fixed via addition of a private capability to subsystem=security/security-domain for use by the infinispan subsystem. Better would be a normal public capability.
Doing this will also mean tightening up the API exposed by the legacy security domain to remove methods that should not be available to callers outside the security subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugi... ]
Josef Cacek resolved WFCORE-2392.
---------------------------------
Fix Version/s: 3.0.0.Beta18
Resolution: Done
> Remoting EJB identity propagation does not work with Elytron
> ------------------------------------------------------------
>
> Key: WFCORE-2392
> URL: https://issues.jboss.org/browse/WFCORE-2392
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: elytron-legacy-test-fails
> Fix For: 3.0.0.Beta18
>
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-8335?page=com.atlassian.jira.plugin.... ]
Claudio Miranda edited comment on WFLY-8335 at 5/8/17 2:41 PM:
---------------------------------------------------------------
Hi Romain, I think there are some problems with the current implementation
1) the r-r-d doesn't set the alternatives correctly, the alternative of "use-jdbc-store" should contains "use-journal-store" and vice-versa.
{code}
"use-jdbc-store" => {
"type" => BOOLEAN,
"description" => "Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"requires" => ["jdbc-store-datasource"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
},
"use-journal-store" => {
"type" => BOOLEAN,
"description" => "Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file system file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
}
{code}
2) when writing both "use-journal-store" and "use-jdbc-store" to true, the operation doesn't fail, it just sets the first one to true and the other to false. But it must fails.
{code}
batch
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-journal-store,value=true)
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-jdbc-store,value=true)
[domain@localhost:9990 / #] run-batch
The batch executed successfully
{code}
I suggest to have a look at subsystem=elytron/dir-context=foo resource on how to handle the alternatives
{code}
[domain@localhost:9990 /] /profile=default/subsystem=elytron/dir-context=foo:add(url="ldap://foobar")
[domain@localhost:9990 /] batch
[domain@localhost:9990 / #] /profile=default/subsystem=elytron/dir-context=foo:write-attribute(name=ssl-context,value="foo2")
[domain@localhost:9990 / #] /profile=default/subsystem=elytron/dir-context=foo:write-attribute(name=authentication-context,value="bar2")
[domain@localhost:9990 / #] run-batch
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => "WFLYCTL0105: ssl-context is invalid in combination with authentication-context"}}
{code}
was (Author: claudio4j):
Hi Romain, I think there are some problems with the current implementation
1) the r-r-d doesn't set the alternatives correctly, the alternative of "use-jdbc-store" should contains "use-journal-store" and vice-versa.
{code}
"use-jdbc-store" => {
"type" => BOOLEAN,
"description" => "Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"requires" => ["jdbc-store-datasource"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
},
"use-journal-store" => {
"type" => BOOLEAN,
"description" => "Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file system file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
}
{code}
2) when writing both "use-journal-store" and "use-jdbc-store" to true, the operation doesn't fail, it just sets the first one to true and the other to false. But it must fails.
{code}
batch
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-journal-store,value=true)
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-jdbc-store,value=true)
[domain@localhost:9990 / #] run-batch
The batch executed successfully
{code}
> User should be informed when switching between JDBC and journal store in transactions subsystem
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-8335
> URL: https://issues.jboss.org/browse/WFLY-8335
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true.
> When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-8335?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-8335:
---------------------------------------
Hi Romain, I think there are some problems with the current implementation
1) the r-r-d doesn't set the alternatives correctly, the alternative of "use-jdbc-store" should contains "use-journal-store" and vice-versa.
{code}
"use-jdbc-store" => {
"type" => BOOLEAN,
"description" => "Use the jdbc store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store is normally one file file per transaction log. It's alternative to journal based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"requires" => ["jdbc-store-datasource"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
},
"use-journal-store" => {
"type" => BOOLEAN,
"description" => "Use the journal store for writing transaction logs. Set to true to enable and to false to use the default log store type. The default log store creates normally one file system file per transaction log. The journal one consists from one file for all the transactions. It's alternative to jdbc based store.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => false,
"alternatives" => ["use-hornetq-store"],
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "jvm"
}
{code}
2) when writing both "use-journal-store" and "use-jdbc-store" to true, the operation doesn't fail, it just sets the first one to true and the other to false. But it must fails.
{code}
batch
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-journal-store,value=true)
[domain@localhost:9990 / #] /profile=default/subsystem=transactions:write-attribute(name=use-jdbc-store,value=true)
[domain@localhost:9990 / #] run-batch
The batch executed successfully
{code}
> User should be informed when switching between JDBC and journal store in transactions subsystem
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-8335
> URL: https://issues.jboss.org/browse/WFLY-8335
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true.
> When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-2746:
------------------------------
Description:
Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
There are a number of aspects to this, for which I'll create subtasks.
Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
org.jboss.as.test.integration.security.perimeter.* [2]
org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
-org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
org.jboss.as.test.integration.security.credentialreference [2] (This is using h2 / datasources, so not moving).
[1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
[2] Currently using Arquillian.
was:
Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
There are a number of aspects to this, for which I'll create subtasks.
Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
org.jboss.as.test.integration.security.perimeter.* [2]
org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
-org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
org.jboss.as.test.integration.security.credentialreference [2] (This is using h2 / datasources, so not moving).
[1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
[2] Currently using Arquillian.
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> org.jboss.as.test.integration.security.perimeter.* [2]
> org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2] (This is using h2 / datasources, so not moving).
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months