[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-2746.
--------------------------------------
Resolution: Out of Date
I'm resolving this as out of date. A lot of work was done for Core 3; see linked subtasks. I don't see a point keeping this open.
> 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
> Fix For: 4.0.0.CR1
>
>
> 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]-
> integration/elytron/
> [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.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2818) move integration/elytron/ tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2818?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2818:
-------------------------------------
Parent: (was: WFCORE-2746)
Issue Type: Task (was: Sub-task)
> move integration/elytron/ tests
> -------------------------------
>
> Key: WFCORE-2818
> URL: https://issues.jboss.org/browse/WFCORE-2818
> Project: WildFly Core
> Issue Type: Task
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> These are a mixture of things using servlet deployments to test various things. Some of them may be movable, but initial attempts proved somewhat complicated.
> I created an undertow with a basic auth mechanism, but it wasn't clear how this should have interacted with elytron, so for example, the elyton audit log test pass the HTTP auth parts (obviously), but fail to write appropriate records into the audit logs.
> Some of them may be re-configurable into testing against mgmt security, I need to take another look.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2818) Move more integration/elytron/ tests from full
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2818?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2818:
-------------------------------------
Summary: Move more integration/elytron/ tests from full (was: move integration/elytron/ tests)
> Move more integration/elytron/ tests from full
> ----------------------------------------------
>
> Key: WFCORE-2818
> URL: https://issues.jboss.org/browse/WFCORE-2818
> Project: WildFly Core
> Issue Type: Task
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> These are a mixture of things using servlet deployments to test various things. Some of them may be movable, but initial attempts proved somewhat complicated.
> I created an undertow with a basic auth mechanism, but it wasn't clear how this should have interacted with elytron, so for example, the elyton audit log test pass the HTTP auth parts (obviously), but fail to write appropriate records into the audit logs.
> Some of them may be re-configurable into testing against mgmt security, I need to take another look.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.CR1)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 5.0.0.Alpha1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore missing RBAC config resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3107:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.CR1)
> Allow slave hosts to ignore missing RBAC config resources
> ---------------------------------------------------------
>
> Key: WFCORE-3107
> URL: https://issues.jboss.org/browse/WFCORE-3107
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 5.0.0.Alpha1
>
>
> Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC.
> If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op.
> This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months