August 2019 - jboss-jira - Jboss List Archives

[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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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 reassigned ELY-1745: -------------------------------- Assignee: (was: Justin Cook) > 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 > 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)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1778?page=com.atlassian.jira.plugin.s... ] Justin Cook edited comment on ELY-1778 at 8/30/19 2:17 PM: ----------------------------------------------------------- Since my internship is finishing today, I'm unassigning myself from the issue and leaving this status update based on my [Elytron branch|https://github.com/justinmcook/wildfly-elytron/tree/ELY-1778]: The security events without a direct legacy equivalent have been added Work has been done on making RealmEventVisitor available in WildFly Core's AuditResourceDefinitions by attempting to create a generic ElytronEvent that can be used The branch is currently incorporates [ELY-1712|https://issues.jboss.org/browse/ELY-1712], which has since been merged and as such future work on this issue no longer needs that commit was (Author: jucook): Since my internship is finishing today, I'm unassigning myself from the issue and leaving this status update based on my [Elytron branch|https://github.com/justinmcook/wildfly-elytron/tree/ELY-1778]: The security events without a direct legacy equivalent have been added Work has been done on making RealmEventVisitor available in WildFly Core's AuditResourceDefinitions by attempting to create a generic ElytronEvent that can be used > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.jboss.org/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.10.0.CR7 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Justin Cook (Jira)

[ https://issues.jboss.org/browse/ELY-1778?page=com.atlassian.jira.plugin.s... ] Justin Cook commented on ELY-1778: ---------------------------------- Since my internship is finishing today, I'm unassigning myself from the issue and leaving this status update based on my [Elytron branch|https://github.com/justinmcook/wildfly-elytron/tree/ELY-1778]: The security events without a direct legacy equivalent have been added Work has been done on making RealmEventVisitor available in WildFly Core's AuditResourceDefinitions by attempting to create a generic ElytronEvent that can be used > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.jboss.org/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.10.0.CR7 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019