[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ]
Jason Greene updated WFCORE-610:
--------------------------------
Fix Version/s: 2.0.0.Alpha4
(was: 2.0.0.Alpha3)
> Integrate Elytron for management security.
> ------------------------------------------
>
> Key: WFCORE-610
> URL: https://issues.jboss.org/browse/WFCORE-610
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.Alpha4
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-609) Administrator Encouragement
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-609?page=com.atlassian.jira.plugin... ]
Jason Greene updated WFCORE-609:
--------------------------------
Fix Version/s: 2.0.0.Alpha4
(was: 2.0.0.Alpha3)
> Administrator Encouragement
> ---------------------------
>
> Key: WFCORE-609
> URL: https://issues.jboss.org/browse/WFCORE-609
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.Alpha4
>
>
> I know the name is not popular so will have a better name ;-)
> Essentially some form of centralised repository to hold warnings raised by subsystems as a server boots.
> Management operations would be provided to query the current warnings.
> As administrators undertake actions to correct a warning it will be dynamically removed by the subsystem that reported it.
> This is not about persistent warnings i.e. the subsystem should raise the warning on every boot and stop raising it if it is no longer relevant.
> e.g. SSL not enabled, warn every time the server starts until it is enabled.
> Warnings will be associated with a severity level and administrative tooling can decide how pro-actively to display the warning, e.g. the console may pop up immediately for a critical warning or use an icon to indicate the presence of a lesser warning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-719) JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-719?page=com.atlassian.jira.plugin... ]
Jason Greene updated WFCORE-719:
--------------------------------
Fix Version/s: 2.0.0.Alpha4
(was: 2.0.0.Alpha3)
> JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-719
> URL: https://issues.jboss.org/browse/WFCORE-719
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 2.0.0.Alpha2
> Reporter: Manuel Blechschmidt
> Assignee: Tomaz Cerar
> Labels: JS223, JavaScript, Scripting
> Fix For: 2.0.0.Alpha4
>
>
> When using the ScriptManager in a JSF bean the following happens:
> ERROR [stderr] (default task-21) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> {code}
> package de.example.log.jsf;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.PrintStream;
> import javax.enterprise.inject.Model;
> import javax.faces.application.FacesMessage;
> import javax.faces.context.FacesContext;
> import javax.inject.Inject;
> import javax.script.Bindings;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> @Model
> public class Scripting {
> private String script;
> private String output;
> private ScriptEngineManager mgr = new ScriptEngineManager();
> public static String utilJavaScript = "var print = function (s) { __newOut.print(s); }; var println = function (s) { __newOut.println(s); };";
> public String execute() {
> ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");
> ByteArrayOutputStream outputBuffer = new ByteArrayOutputStream(8192);
> PrintStream newOut = new PrintStream(outputBuffer, true);
> Bindings bindings = jsEngine.createBindings();
> bindings.put("__newOut", newOut);
> try {
> jsEngine.eval(utilJavaScript + getScript(), bindings);
> } catch (ScriptException from) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(from.getColumnNumber() + " "
> + from.getFileName() + " " + from.getLineNumber()
> + " " + from.getMessage()));
> return null;
> }
> newOut.close();
> String returnString = outputBuffer.toString();
> setOutput(returnString);
> try {
> outputBuffer.close();
> } catch (IOException e) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(e.getLocalizedMessage()));
> }
> return null;
> }
> public String getScript() {
> return script;
> }
> public void setScript(String script) {
> this.script = script;
> }
> public String getOutput() {
> return output;
> }
> public void setOutput(String output) {
> this.output = output;
> }
> }
> {code}
> The script engines are configured in the following file:
> WILDFLY_HOME/modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory
> {code}
> com.sun.script.javascript.RhinoScriptEngineFactory
> jdk.nashorn.api.scripting.NashornScriptEngineFactory
> {code}
> It should be made sure that with every JDK JSR 223 compliant requests for a JavaScript engine will work out of the box.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-716) Once server in reload-required state capabilities no longer checked at stage Model.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-716?page=com.atlassian.jira.plugin... ]
Jason Greene updated WFCORE-716:
--------------------------------
Fix Version/s: 2.0.0.Alpha4
(was: 2.0.0.Alpha3)
> Once server in reload-required state capabilities no longer checked at stage Model.
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-716
> URL: https://issues.jboss.org/browse/WFCORE-716
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha2
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 2.0.0.Alpha4
>
>
> Once a server is in the state reload-required capabilities and requirements are no longer checked e.g.: -
> {noformat}
> [standalone@localhost:9990 /] ./core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> The following command is referencing a non-existent capability: -
> {noformat}
> [standalone@localhost:9990 /] ./core-service=management/management-interface=http-interface:write-attribute(name=security-domain, value=MgMtDom)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> When I execute :reload it will fail: -
> {noformat}
> 11:21:18,567 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("core-service" => "management"),
> ("management-interface" => "http-interface")
> ]): java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.security.security-domain.MgMtDom' is unknown.
> at org.jboss.as.controller.ModelControllerImpl$CapabilityRegistryImpl.getCapabilityRegistration(ModelControllerImpl.java:1388)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-713) Add capability registrations for the management interfaces.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-713?page=com.atlassian.jira.plugin... ]
Jason Greene updated WFCORE-713:
--------------------------------
Fix Version/s: 2.0.0.Alpha4
(was: 2.0.0.Alpha3)
> Add capability registrations for the management interfaces.
> -----------------------------------------------------------
>
> Key: WFCORE-713
> URL: https://issues.jboss.org/browse/WFCORE-713
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 2.0.0.Alpha4
>
>
> So that the management interfaces can register capabilities they are dependent on they first need to be registered as providing a capability.
> In this case the management interfaces are not dynamic capabilities so a fully qualified name can be used, just need to differentiate between native and http.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4515) Fix clustering transformers and reenable in mixed-domain tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4515?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-4515:
--------------------------------------
Update: on the call today we agreed to hardcode paths in jgroups subsystem referencing infinispan subsystem to avoid the cyclical dependency this would otherwise cause. This is already the case with ee subsystem references, there is no viable option to decouple the paths from the resource, transformers code can be considered temporary, etc.
> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
> Key: WFLY-4515
> URL: https://issues.jboss.org/browse/WFLY-4515
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 9.0.0.Beta2
> Reporter: Kabir Khan
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests.
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
> ("profile" => "full-ha"),
> ("subsystem" => "infinispan"),
> ("cache-container" => "server"),
> ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> /subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extensi... so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4515) Fix clustering transformers and reenable in mixed-domain tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4515?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4515:
---------------------------------
Fix Version/s: 10.0.0.Alpha3
> Fix clustering transformers and reenable in mixed-domain tests
> --------------------------------------------------------------
>
> Key: WFLY-4515
> URL: https://issues.jboss.org/browse/WFLY-4515
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 9.0.0.Beta2
> Reporter: Kabir Khan
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests.
> Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
> Some info from private mail:
> {quote}
> However, when transforming that to 7.2.0 by running:
> mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
> I get the following error:
> 11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
> ("profile" => "full-ha"),
> ("subsystem" => "infinispan"),
> ("cache-container" => "server"),
> ("transport" => "TRANSPORT")
> ] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
> I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
> /subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
> and the stack does not get persisted.
> It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extensi... so that we can support old configs, but not actually use it on a server using the current version?
> {quote}
> Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month