[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2016:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> Change sasl-authentication-factor for management auth works after reload, but not after server restart
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2016
> URL: https://issues.jboss.org/browse/WFCORE-2016
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Zach Rhoads
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha24
>
>
> I can successfully configure a new sasl-authentication-factory and assign it to the management interface:
> {code}
> /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"})
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"])
> /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
> /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper)
> /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}])
> /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)
> reload
> {code}
> after reload, i am forced to re-authenticate and it succeeds:
> {code}
> [standalone@localhost:9990 /] reload
> Authenticating against security realm: exampleSaslRealm
> Username: user1
> Password:
> [standalone@localhost:9990 /]
> {code}
> Once i restart the server though and try to connect, i get a timeout:
> {code}
> $ ./jboss-cli.sh -c
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}
> It also fails if i force no local auth:
> {code}
> $ ./jboss-cli.sh -c --no-local-auth
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}/
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2046:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> KeyManager synchronization issue when using IBM JDK
> ---------------------------------------------------
>
> Key: WFCORE-2046
> URL: https://issues.jboss.org/browse/WFCORE-2046
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha24
>
> Attachments: test-app-ibm-jdk-keymanager-sync.zip
>
>
> We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords.
> As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines.
> Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}).
> The workflow:
> # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}}
> # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}}
> # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore.
> *Possible workaround*
> We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2163:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2163
> URL: https://issues.jboss.org/browse/WFCORE-2163
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha24
>
>
> In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started.
> I am using following configuration for HTTP management interface (see Steps to Reproduce for more details):
> {code}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
> <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {code}
> Server is not started and following errors occur in log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided.
> at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225)
> at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254)
> at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107)
> at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589)
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292)
> ... 5 more
> {code}
> and
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service
> Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}
> According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication.
> [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2249) ObjectTypeValidator only validates fields the user provides
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2249?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2249:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> ObjectTypeValidator only validates fields the user provides
> -----------------------------------------------------------
>
> Key: WFCORE-2249
> URL: https://issues.jboss.org/browse/WFCORE-2249
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha24
>
>
> This in ObjectTypeValidator is wrong:
> {code}
> @Override
> public void validateParameter(final String parameterName, final ModelNode value) throws OperationFailedException {
> super.validateParameter(parameterName, value);
> if (value.isDefined()) {
> for (String key : value.keys()) {
> if (allowedValues.containsKey(key)) {
> allowedValues.get(key).getValidator().validateParameter(key, value.get(key));
> } else {
> throw ROOT_LOGGER.invalidKeyForObjectType(key, parameterName);
> }
> }
> }
> }
> {code}
> 1) It only iterates over the keys in 'value' so if value is missing any required fields that isn't detected.
> 2) It's not really appropriate to reject keys that are not part of the definition. The management code is meant to be forgiving in such cases.
> For now I think I'll just focus on #1. It's debatable whether being forgiving is really ideal in general, and since this particular bit of unforgivingness has been around since at least 2012 I think I'll leave it alone.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2264) Missing capability tab completion on object type attributes
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2264:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> Missing capability tab completion on object type attributes
> -----------------------------------------------------------
>
> Key: WFCORE-2264
> URL: https://issues.jboss.org/browse/WFCORE-2264
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha22
> Environment: Reproducible using current WildFly master
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha24
>
>
> The following command is valid: -
> {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}
> However tab completion is not possible to discover the available capabilities for the value.
> I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.
> (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2217:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2217
> URL: https://issues.jboss.org/browse/WFCORE-2217
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha16
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha24, 4.0.0.Beta1
>
>
> During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called.
> The fix is quite simple:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full.
> I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives.
> For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> So although the fix is simple, the fallout of this is quite big.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2245:
-------------------------------
Fix Version/s: 3.0.0.Alpha24
(was: 3.0.0.Alpha23)
> credential-reference capability-reference constraint
> ----------------------------------------------------
>
> Key: WFCORE-2245
> URL: https://issues.jboss.org/browse/WFCORE-2245
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha24
>
>
> There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement.
> {code}
> "credential-reference" => {
> "type" => OBJECT,
> "description" => "Credential (from Credential Store) to authenticate on data source",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.credential-store",
> "access-constraints" => {"sensitive" => {
> "credential" => {"type" => "core"},
> "data-source-security" => {"type" => "datasources"}
> }},
> "value-type" => {
> "store" => {
> "type" => STRING,
> "description" => "The name of the credential store holding the alias to credential",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "alias" => {
> "type" => STRING,
> "description" => "The alias which denotes stored secret or credential in the store",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "type" => {
> "type" => STRING,
> "description" => "The type of credential this reference is denoting",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "clear-text" => {
> "type" => STRING,
> "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months