[JBoss JIRA] (WFCORE-2468) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2468?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski resolved WFCORE-2468.
----------------------------------------
Fix Version/s: 3.0.1.Final
Resolution: Out of Date
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2468
> URL: https://issues.jboss.org/browse/WFCORE-2468
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Bartosz Baranowski
> Fix For: 3.0.1.Final
>
>
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> *Steps to reproduce*
> * firefly.keystore which is attached copy to eap_home/standalone/data/cs.
> * /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron})
> */subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001)
> And you get this output:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store.
> When I add there credential-reference with pass to Key-store then operation passes
> /subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron})
> *Suggestions to improvement*
> failure-description must not contain Exception or snippet stacktrace.
> Please replace WFLYCTL0080 part to better message.
> e.g. "credential-reference is required", "Missing password to key-store access"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2468) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2468?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFCORE-2468:
------------------------------------------
Assignee: Bartosz Baranowski
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2468
> URL: https://issues.jboss.org/browse/WFCORE-2468
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Bartosz Baranowski
>
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> *Steps to reproduce*
> * firefly.keystore which is attached copy to eap_home/standalone/data/cs.
> * /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron})
> */subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001)
> And you get this output:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store.
> When I add there credential-reference with pass to Key-store then operation passes
> /subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron})
> *Suggestions to improvement*
> failure-description must not contain Exception or snippet stacktrace.
> Please replace WFLYCTL0080 part to better message.
> e.g. "credential-reference is required", "Missing password to key-store access"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Giovanni Lovato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Giovanni Lovato commented on WFLY-9053:
---------------------------------------
[~smarlow] So any chance to use ORM 5.2 in WildFly 11? Is this a Hibernate issue?
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Alpha1
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2214:
--------------------------------
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2214 at 8/29/17 3:23 AM:
---------------------------------------------------------
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
was (Author: belaban):
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2214:
---------------------------
Attachment: CertficateCNMatcher.java
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/29/17 2:49 AM:
------------------------------------------------------------------------
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.
But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.
I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.
On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via eclipse or startup bat.
I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.
I believe there is a bug here.
- The behavior is not deterministic
- The behavior typically demonstrates the class isolation that the module architecture is working most of the time
- It also shows that sometimes as a side effect of depending org.jboss.logmanager you module class loader is soiled but the log4j packages.
And the module architecture apparently should allow a module A (our routing module) to depend on a module B (org.jboss.logmanager) without being forced to be corruped by all the dependnecies e.g module C (org.jboss.log4j) that are transitive to module B.
And this behavior seems to work most of the time but not all of the time.
- I believe I will ask for permission to give you a configuration with this router logger.
To demonstrate the issue on startup.
Because then you would quite clearly see that there is a problem here.
Many thanks for all the Input.
was (Author: nuno.godinhomatos):
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.
But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.
I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.
On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via eclipse or startup bat.
I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.
Soithinkthereismost definitely about here.
Many thanks for all the Input.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
Bela Ban created JGRP-2214:
------------------------------
Summary: SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
Key: JGRP-2214
URL: https://issues.jboss.org/browse/JGRP-2214
Project: JGroups
Issue Type: Feature Request
Affects Versions: 4.0.5
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.6
In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
If this is not the case, terminate the SSL connection.
Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months