[JBoss JIRA] (WFCORE-2821) Elytron two way SSL with CRL set does not work
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2821?page=com.atlassian.jira.plugi... ]
Kabir Khan resolved WFCORE-2821.
--------------------------------
Fix Version/s: 3.0.0.Beta22
Resolution: Done
> Elytron two way SSL with CRL set does not work
> ----------------------------------------------
>
> Key: WFCORE-2821
> URL: https://issues.jboss.org/browse/WFCORE-2821
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta21
> Reporter: Ondrej Kotek
> Priority: Blocker
> Labels: eap7.1-rfe-blocker
> Fix For: 3.0.0.Beta22
>
>
> Having set two way SSL Elytron {{server-ssl-context}} [1] but with {{trust-managers}} with {{certificate-revocation-list}} set (and {{algorithm}} unset), a client is not able to connect to the server, because the server closes connections.
> Debugging reveals that just {{getAcceptedIssuers}} method is called on {{X509CRLExtendedTrustManager}} and returns {{null}} (as set from the subsystem).
> There is also unexpected error in server log (twice):
> {noformat}
> ERROR [org.xnio.nio] (default I/O-3) XNIO000011: Task io.undertow.protocols.ssl.SslConduit$5$1@106b714d failed with an exception: java.lang.RuntimeException: Delegated task threw Exception/Error
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1429)
> at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:73)
> at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:749)
> at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:646)
> at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
> at io.undertow.protocols.ssl.SslConduit$5$1.run(SslConduit.java:1046)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> Caused by: java.lang.NullPointerException
> at sun.security.ssl.HandshakeMessage$CertificateRequest.<init>(HandshakeMessage.java:1306)
> at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:963)
> at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:221)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
> at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1034)
> 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)
> {noformat}
> The CRL functionality is required by EAP7-203, hence Blocker priority is set.
> [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildF...
> [2] https://docs.jboss.org/author/display/WFLY/SSL+Configuration+using+Elytro...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8842) Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8842:
---------------------------------
Summary: Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases
Key: WFLY-8842
URL: https://issues.jboss.org/browse/WFLY-8842
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Blocker
In our tests for PLAIN SASL mechanism in the AS testsuite we realized a wrong SaslClient implementation is used. Instead of the Elytron one, the JDK provided one is used ({{com.sun.security.sasl.PlainClient}}).
The Elytron client builds the AuthenticationContext and runs executed code in this way:
{code:java}
AuthenticationConfiguration authnCfg = AuthenticationConfiguration.EMPTY.allowSaslMechanisms(MECHANISM_PLAIN)
.useName(USERNAME).usePassword("wrongPassword")
.useProviders(() -> new Provider[] { new WildFlyElytronProvider() });
AuthenticationContext.empty().with(MatchRule.ALL, authnCfg).run(...)
{code}
It seems to be related to what's included on classpath. When we use the same code in [elytron-client-demo|https://github.com/jboss-security-qe/elytron-client-demo] the correct mechanism is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1579) Using salience with parallel agenda
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1579:
-------------------------------------
Summary: Using salience with parallel agenda
Key: DROOLS-1579
URL: https://issues.jboss.org/browse/DROOLS-1579
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 7.0.0.Final
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Priority: Minor
Using salience with parallel agenda is probably not feasible, because salience is ordering of rules and ordering introduces rule serialization. However we should discuss this more so we know 100% that there are no feasible solutions.
One possible scenario could be to put all salienced rules (and relatives according to rete) to separate partition, which is handled by separate agenda and process this agenda before all other agendas. In such case these "other" agendas could be processed in parallel after the "salienced" agenda is processed. Other name for this feature could be "postponed partitioning". First process everything that cannot be partitioned and then process everything that is partitioned in parallel.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1495) Partition also ObjectTypeNodes when using parallel agenda
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1495?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-1495:
----------------------------------
Labels: parallel-agenda reported-by-qe (was: reported-by-qe)
> Partition also ObjectTypeNodes when using parallel agenda
> ---------------------------------------------------------
>
> Key: DROOLS-1495
> URL: https://issues.jboss.org/browse/DROOLS-1495
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.0.0.Beta7
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Priority: Minor
> Labels: parallel-agenda, reported-by-qe
>
> Currently we don't parallelize ObjectTypeNodes. They are part of MAIN partition. The parallelization starts then after OTNs. This limitation doesn't introduce performance gains for scenarios, where only one partition is after each OTN. The better approach would be to have the Rete network partitioned right from Entry Point.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months