October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4486) Support for multiple security realms - Failover

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4486?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4486: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Support for multiple security realms - Failover > ----------------------------------------------- > > Key: WFCORE-4486 > URL: https://issues.redhat.com/browse/WFCORE-4486 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Martin Mazánek > Priority: Major > Labels: CD17-Deferred > Fix For: 13.0.0.Beta5 > > > Our security realms are able to indicate unavailability by throwing a RealmUnavailableException > We should support fail over to an alternative realm. > A common request is fail over to a local file based realm if an LDAP or database server has gone down allowing administrators to retain access to the server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4484) Support SSH authentication for Git persistence

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4484?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4484: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Support SSH authentication for Git persistence > ---------------------------------------------- > > Key: WFCORE-4484 > URL: https://issues.redhat.com/browse/WFCORE-4484 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: EAP-CD19 > Fix For: 13.0.0.Beta5 > > > Currently Elytron only supports authentication for HTTP(s) URLS so there is no way to connect to a SSH git server to pull/push configuration history -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4853) [GSS][7.2.2] HTTP External Security Not Supported by Elytron

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4853?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4853: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > [GSS][7.2.2] HTTP External Security Not Supported by Elytron > ------------------------------------------------------------ > > Key: WFCORE-4853 > URL: https://issues.redhat.com/browse/WFCORE-4853 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Ashley Abdel-Sayed > Assignee: Ashley Abdel-Sayed > Priority: Major > Fix For: 13.0.0.Beta6 > > > Add EXTERNAL HTTP authentication mechanism to WildFly -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5010) Startup error messages caused by expression where expressions are not allowed are confusing

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5010?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5010: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Startup error messages caused by expression where expressions are not allowed are confusing > ------------------------------------------------------------------------------------------- > > Key: WFCORE-5010 > URL: https://issues.redhat.com/browse/WFCORE-5010 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Ondrej Chaloupka > Assignee: Lukas Vydra > Priority: Minor > Fix For: 13.0.0.Beta6 > > > When a property expression is used at place where expression usage is not allowed then error message which is shown is quite confusing. From user point of view (especially the newcomer) it would be nice if the error message shows the real reason - usage of expression at place where is not permitted. > Maybe CLI could warn on usage of expression on place where is not allowed too. > Documentation recommends configuration with CLI, editing of XML file is common too. More of it there are some tasks which are harder to be done with CLI and editing XML is faster/easier. > Examples: > Setting > {code} > /subsystem=ee/managed-executor-service=default:write-attribute(name=context-service, value="${my.context.service}") > {code} > ends with this error message during startup > {code} > 14:13:21,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "ee"), > ("managed-executor-service" => "default") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.concurrent.ee.context.service.${my.context.service}"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.concurrent.ee.executor.default is missing [jboss.concurrent.ee.context.service.${my.context.service}]"]} > {code} > another confusion is setting name of host in {{host-slave.xml}} file. When set as > {code} > <host xmlns="urn:jboss:domain:4.2" host="${host.name}"> > {code} > then NullPointerException is thrown. > {code} > [Host Controller] 14:18:45,238 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188) > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:594) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745)[Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError > at [row,col]:[3,1][Host Controller] Message: WFLYCTL0197: Unexpected attribute 'host' encountered > at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117) > at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:311) > at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 4 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4956) EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z]

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4956?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4956: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z] > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4956 > URL: https://issues.redhat.com/browse/WFCORE-4956 > Project: WildFly Core > Issue Type: Bug > Components: Embedded > Reporter: Kunjan Rathod > Assignee: James Perkins > Priority: Minor > Labels: CVE-2020-10718, Security, SecurityTracking, downstream_dependency, pscomponent:wildfly > Fix For: 13.0.0.Beta5 > > > Security Tracking Issue > Do not make this issue public. > Impact: Low > Public Date: not set > Resolve Bug By: 545 calendar days from the public date > In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug. > Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB > NOTE THIS ISSUE IS CURRENTLY EMBARGOED, DO NOT MAKE PUBLIC COMMITS OR COMMENTS ABOUT THIS ISSUE. > Flaw: > ----- > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API > https://bugzilla.redhat.com/show_bug.cgi?id=1828476 > The embedded managed process API has two methods exposed as public methods which can bypass the security manager. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5069) libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5069?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5069: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider > ------------------------------------------------------------------------------------- > > Key: WFCORE-5069 > URL: https://issues.redhat.com/browse/WFCORE-5069 > Project: WildFly Core > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 13.0.0.Beta5 > > > Looks like detection of `libwfssl` is broken in current build. When I try to configure OpenSSL security provider in legacy security, I can see following errors in standalone.log: > {code:java} > 15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748)Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) at java.security.Provider$Service.newInstance(Provider.java:1617) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105) ... 8 moreCaused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:87) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi.<init>(OpenSSLContextSPI.java:484) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.security.Provider$Service.newInstance(Provider.java:1595) ... 12 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.wildfly.openssl.SSL.init(SSL.java:82) ... 19 moreCaused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1124) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288) ... 24 more > 15:39:44,818 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("security-realm" => "ApplicationRealm")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context" => "WFLYDM0018: Unable to start service Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.reflect.InvocationTargetException Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"}} {code} > > This is a regression against previous release - {{EAP7.3.1}}. Expected behaviour is no error in the log, libwfssl is loaded successfully and OpenSSL is correctly used for TLS connections. > Note - there has been a change in the location of the particular libwfssl native binaries in the distribution, see https://github.com/wildfly-security/wildfly-openssl/commit/c5c07d3dc0d637... > {code:title=7.3.1} > $ find . -name *wfssl* > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so > {code} > and > {code:title=7.4.0.CD20-CR1} > $ find . -name *ssl* > ./modules/system/layers/base/org/wildfly/openssl > ./modules/system/layers/base/org/wildfly/openssl/main/wildfly-openssl-java-1.1.0.Final-redhat-00001.jar > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el8-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el7-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-ssl-1.12.1.Final-redhat-00001.jar > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5084) Why does the elytron layer bring in access control?

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5084?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5084: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Why does the elytron layer bring in access control? > --------------------------------------------------- > > Key: WFCORE-5084 > URL: https://issues.redhat.com/browse/WFCORE-5084 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > The following shows the set of changes created by adding the elytron layer to a provisioned server: > https://gist.github.com/darranl/68f4a3d60560dae9a9225ec1a0e35a9f/revisions > This includes the following: > {code:xml} > <management> > <access-control provider="simple"> > <role-mapping> > <role name="SuperUser"> > <include> > <user name="$local"/> > </include> > </role> > </role-mapping> > </access-control> > </management> > {code} > Shouldn't this section be added if any form of authenticated management is added instead? -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5079: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5075) Upgrade WildFly OpenSSL to 1.1.2.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5075?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5075: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Upgrade WildFly OpenSSL to 1.1.2.Final > -------------------------------------- > > Key: WFCORE-5075 > URL: https://issues.redhat.com/browse/WFCORE-5075 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 13.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5076) remoting http-connector silently accepts invalid security-realm

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5076?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5076: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > remoting http-connector silently accepts invalid security-realm > --------------------------------------------------------------- > > Key: WFCORE-5076 > URL: https://issues.redhat.com/browse/WFCORE-5076 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > If the remoting subsystem is changed to the following: > {code:xml} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/> > </subsystem> > {code} > The server starts without error, however attempting to establish a connection fails. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200 > {code} > Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020