[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2497:
-------------------------------------
Fix Version/s: 4.0.0.Alpha5
(was: 4.0.0.Alpha4)
> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2497
> URL: https://issues.jboss.org/browse/WFCORE-2497
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Fix For: 4.0.0.Alpha5
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-3382) Further Enhance Elytron Permission Configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3382:
-------------------------------------
Fix Version/s: 4.0.0.Alpha5
(was: 4.0.0.Alpha4)
> Further Enhance Elytron Permission Configuration
> ------------------------------------------------
>
> Key: WFCORE-3382
> URL: https://issues.jboss.org/browse/WFCORE-3382
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Fix For: 4.0.0.Alpha5
>
>
> This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location.
> Finding a way for the default required permissions to be defined in one location could help eliminate the duplication.
> We could also consider going one step further and subsystems register the default permissions that should be granted.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3255:
-------------------------------------
Fix Version/s: 4.0.0.Alpha5
(was: 4.0.0.Alpha4)
> Complex type AttributeDefinition variants don't handle ParameterCorrector properly
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3255
> URL: https://issues.jboss.org/browse/WFCORE-3255
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha5
>
>
> If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called.
> These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-3181) Review CustomCredentialSecurityFactoryTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3181:
-------------------------------------
Fix Version/s: 4.0.0.Alpha5
(was: 4.0.0.Alpha4)
> Review CustomCredentialSecurityFactoryTestCase
> ----------------------------------------------
>
> Key: WFCORE-3181
> URL: https://issues.jboss.org/browse/WFCORE-3181
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Test Suite
> Reporter: Darran Lofthouse
> Fix For: 4.0.0.Alpha5
>
>
> The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'.
> The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory.
> Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail.
> If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-3167) option to filter out aged out patches from the patching history
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3167?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3167:
-------------------------------------
Fix Version/s: 4.0.0.Alpha5
(was: 4.0.0.Alpha4)
> option to filter out aged out patches from the patching history
> ---------------------------------------------------------------
>
> Key: WFCORE-3167
> URL: https://issues.jboss.org/browse/WFCORE-3167
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Patching
> Affects Versions: 3.0.0.Beta30
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 4.0.0.Alpha5
>
>
> show-history management operation (and patch history cli command) returns all the patches that have been applied to the installation even if some of them have been aged out by executing ageout-history management operation.
> In some cases it would be useful to filter out the aged out patches from the result, leaving only the patches that can actually be rolled back by a user.
> That could be achieved by adding an optional boolean parameter exclude-agedout (with default value false to preserve the current behavior) to show-history operation.
> The high level CLI command patch history could include an equivalent --exclude-agedout argument.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months