[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1145:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Beta2
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1802:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> Integrate OpenSSL Provider registration with Elytron
> ----------------------------------------------------
>
> Key: WFCORE-1802
> URL: https://issues.jboss.org/browse/WFCORE-1802
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Stuart Douglas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta2
>
>
> We need to remove the following block from SecurityRealmResourceDefinition: -
> {code}
> static {
> //register the Openssl Provider, if possible
> //not really sure if this is the best place for it
> try {
> OpenSSLProvider.register();
> DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider();
> } catch (Throwable t){
> DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider");
> }
> }
> {code}
> Registration will then be possible within the Elytron subsystem configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 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 Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1649:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> 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
> Fix For: 3.0.0.Beta2
>
>
> 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.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly handles duplicate module names
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1717:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
> Key: WFCORE-1717
> URL: https://issues.jboss.org/browse/WFCORE-1717
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Toby Crawley
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta2
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
> IllegalStateException that occurs when trying to generate the
> XMLStreamException
> (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1962) Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1962?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1962:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1962
> URL: https://issues.jboss.org/browse/WFCORE-1962
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta2
>
>
> The ParameterValidator.validateResolvedParameter method specifies the impl should call ModelNode.resolve() and then validate that. This is a broken contract as ModelNode.resolve() is not the expression resolution mechanism of WildFly.
> This code is only used in a few places. The normal way resolution + validation happens is outside code (e.g. AttributeDefinition) resolves the value and then calls the normal ParameterValidator.validateParameter method.
> So, task here is to look into the few uses of this method in core and full, determine they can be changed to no longer use it, change them, then deprecate this method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1960:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
> Key: WFCORE-1960
> URL: https://issues.jboss.org/browse/WFCORE-1960
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta2
>
> Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute.
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1958:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> Clean up testsuite Elytron registration
> ---------------------------------------
>
> Key: WFCORE-1958
> URL: https://issues.jboss.org/browse/WFCORE-1958
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta2
>
>
> In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them..
> Also re-enable the following test case: -
> * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months