August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1765?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1765: ---------------------------- Fix Version/s: 1.10.1.CR1 (was: 1.10.0.Final) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.jboss.org/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.10.1.CR1 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1866) Broken symbolic link to LICENSE.txt

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/ELY-1866?page=com.atlassian.jira.plugin.s... ] Ashley Abdel-Sayed reassigned ELY-1866: --------------------------------------- Assignee: Ashley Abdel-Sayed > Broken symbolic link to LICENSE.txt > ----------------------------------- > > Key: ELY-1866 > URL: https://issues.jboss.org/browse/ELY-1866 > Project: WildFly Elytron > Issue Type: Bug > Components: Build > Affects Versions: 1.10.0.CR6 > Reporter: Jan Blizňák > Assignee: Ashley Abdel-Sayed > Priority: Major > > The symbolic link https://github.com/wildfly-security/wildfly-elytron/blob/1.x/LICENSE.txt is broken, pointing to non-existent file > {code:java} > $ find | grep LICENSE.txt | xargs file > ./tool/LICENSE.txt: symbolic link to src/main/resources/META-INF/LICENSE.txt > ./tool/src/main/resources/META-INF/LICENSE.txt: ASCII text > ./LICENSE.txt: broken symbolic link to src/main/resources/META-INF/LICENSE.txt > {code} > From above findings it seems the link should be redirected to > {code:java} > tool/src/main/resources/META-INF/LICENSE.txt > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4494) DMN FEELFunction NI

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4494: -------------------------------------- Summary: DMN FEELFunction NI Key: DROOLS-4494 URL: https://issues.jboss.org/browse/DROOLS-4494 Project: Drools Issue Type: Enhancement Components: dmn engine Environment: OpenJDK 64-Bit GraalVM CE 19.2.0 (build 25.222-b08-jvmci-19.2-b02, mixed mode) Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1723) Separate auth client parsing from the API.

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1723?page=com.atlassian.jira.plugin.s... ] Justin Cook commented on ELY-1723: ---------------------------------- Since my internship is available today, I am unassigning myself from this issue. Work done so far on moving the corresponding classes and incorporating providers is available at my [tracking branch on Github|https://github.com/justinmcook/wildfly-elytron/tree/ELY-1723-with-...] > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.jboss.org/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Blocker > Fix For: 2.0.0.Alpha5, 1.10.0.CR7 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1723) Separate auth client parsing from the API.

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1723?page=com.atlassian.jira.plugin.s... ] Justin Cook reassigned ELY-1723: -------------------------------- Assignee: (was: Justin Cook) > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.jboss.org/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 2.0.0.Alpha5, 1.10.0.CR7 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1724?page=com.atlassian.jira.plugin.s... ] Justin Cook commented on ELY-1724: ---------------------------------- Since my internship is available today, I am unassigning myself from this issue. > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.jboss.org/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Critical > Fix For: 2.0.0.Alpha5, 1.10.0.CR7 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1724?page=com.atlassian.jira.plugin.s... ] Justin Cook reassigned ELY-1724: -------------------------------- Assignee: (was: Justin Cook) > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.jboss.org/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 2.0.0.Alpha5, 1.10.0.CR7 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ] Justin Cook commented on ELY-1648: ---------------------------------- Since my internship is finishing today, I am unassigning myself from this issue > FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509 > ----------------------------------------------------------------------------------- > > Key: ELY-1648 > URL: https://issues.jboss.org/browse/ELY-1648 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.5.5.Final > Reporter: Martin Choma > Assignee: Justin Cook > Priority: Major > Attachments: java.security, wildfly-config.xml > > > With SunX509 truststore algorithm I can succesfully connect with CLI. > {code} > <configuration> > <authentication-client xmlns="urn:elytron:client:1.1"> > <key-stores> > <key-store name="truststore" type="PKCS11"> > <key-store-clear-password password="${password}" /> > </key-store> > </key-stores> > <ssl-contexts> > <ssl-context name="client-cli-context"> > <trust-manager algorithm="SunX509" /> > <trust-store key-store-name="truststore" /> > <cipher-suite selector="${cipher.suite.filter}" /> > <protocol names="${protocol}" /> > </ssl-context> > </ssl-contexts> > <ssl-context-rules> > <rule use-ssl-context="client-cli-context" /> > </ssl-context-rules> > </authentication-client> > </configuration> > {code} > But there is a exception in log > {code} > 13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main) java.security.KeyStoreException: JKS not found > at java.security.KeyStore.getInstance(KeyStore.java:851) > at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59) > at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52) > at sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214) > at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164) > at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118) > at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157) > at sun.security.validator.Validator.validate(Validator.java:260) > at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) > at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281) > at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) > at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) > at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) > at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) > at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) > at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543) > at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314) > at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204) > at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98) > at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72) > at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available > at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) > at java.security.Security.getImpl(Security.java:695) > at java.security.KeyStore.getInstance(KeyStore.java:848) > ... 31 more > {code} > When I change SunX509 to PKIX exception does not occure anymore. > Seems exception is thrown by code https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/... > AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided. -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ] Justin Cook reassigned ELY-1648: -------------------------------- Assignee: (was: Justin Cook) > FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509 > ----------------------------------------------------------------------------------- > > Key: ELY-1648 > URL: https://issues.jboss.org/browse/ELY-1648 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.5.5.Final > Reporter: Martin Choma > Priority: Major > Attachments: java.security, wildfly-config.xml > > > With SunX509 truststore algorithm I can succesfully connect with CLI. > {code} > <configuration> > <authentication-client xmlns="urn:elytron:client:1.1"> > <key-stores> > <key-store name="truststore" type="PKCS11"> > <key-store-clear-password password="${password}" /> > </key-store> > </key-stores> > <ssl-contexts> > <ssl-context name="client-cli-context"> > <trust-manager algorithm="SunX509" /> > <trust-store key-store-name="truststore" /> > <cipher-suite selector="${cipher.suite.filter}" /> > <protocol names="${protocol}" /> > </ssl-context> > </ssl-contexts> > <ssl-context-rules> > <rule use-ssl-context="client-cli-context" /> > </ssl-context-rules> > </authentication-client> > </configuration> > {code} > But there is a exception in log > {code} > 13:58:27,652 INFO [com.redhat.eap.qe.cli.CustomCLIExecutor] (main) java.security.KeyStoreException: JKS not found > at java.security.KeyStore.getInstance(KeyStore.java:851) > at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:59) > at sun.security.util.AnchorCertificates$1.run(AnchorCertificates.java:52) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.util.AnchorCertificates.<clinit>(AnchorCertificates.java:52) > at sun.security.provider.certpath.AlgorithmChecker.checkFingerprint(AlgorithmChecker.java:214) > at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:164) > at sun.security.provider.certpath.AlgorithmChecker.<init>(AlgorithmChecker.java:118) > at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:157) > at sun.security.validator.Validator.validate(Validator.java:260) > at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) > at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281) > at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) > at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) > at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) > at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) > at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) > at java.security.AccessController.doPrivileged(Native Method) > at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) > at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:543) > at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:314) > at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:204) > at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98) > at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72) > at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Caused by: java.security.NoSuchAlgorithmException: JKS KeyStore not available > at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) > at java.security.Security.getImpl(Security.java:695) > at java.security.KeyStore.getInstance(KeyStore.java:848) > ... 31 more > {code} > When I change SunX509 to PKIX exception does not occure anymore. > Seems exception is thrown by code https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/sun/... > AnchorCertificates hardcodes JKS keystore creation. Apparently using PKIX it is avoided. -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1745?page=com.atlassian.jira.plugin.s... ] Justin Cook commented on ELY-1745: ---------------------------------- Since my internship is finishing today, I am unassigning myself from this issue. Work done so far is available on my clone of the [WildFly Elytron repository|https://github.com/justinmcook/wildfly-elytron/tree/ELY-1745] > The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1745 > URL: https://issues.jboss.org/browse/ELY-1745 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Major > Fix For: 1.10.0.CR7 > > > The NPE is due to the following code: - > {noformat} > } else if (callback instanceof AvailableRealmsCallback) { > Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames(); > if (log.isTraceEnabled()) { > log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names)); > } > if (! names.isEmpty()) { > ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()])); > } > handleOne(callbacks, idx + 1); > {noformat} > If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list. -- This message was sent by Atlassian Jira (v7.13.5#713005)

4 years, 8 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 August 2019