[JBoss JIRA] (WFLY-11013) Hash encoding Exception when using @DatabaseIdentityStoreDefinition
by Francesco Marchioni (JIRA)
[ https://issues.jboss.org/browse/WFLY-11013?page=com.atlassian.jira.plugin... ]
Francesco Marchioni updated WFLY-11013:
---------------------------------------
Attachment: javaee8-secure-servlet.zip
> Hash encoding Exception when using @DatabaseIdentityStoreDefinition
> -------------------------------------------------------------------
>
> Key: WFLY-11013
> URL: https://issues.jboss.org/browse/WFLY-11013
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 14.0.0.Final
> Environment: WildFly 14. Generic Linux. JDK 8/9
> Reporter: Francesco Marchioni
> Assignee: Darran Lofthouse
> Attachments: javaee8-secure-servlet.zip
>
>
> When deploying one application using @DatabaseIdentityStoreDefinition, upon successful login, the following exception is thrown
> {code:java}
> java.lang.IllegalArgumentException: Bad hash encoding
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.decode(Pbkdf2PasswordHashImpl.java:209)
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.<init>(Pbkdf2PasswordHashImpl.java:191)
> at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl.verify(Pbkdf2PasswordHashImpl.java:147)
> at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:121)
> at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:101)
> at org.jboss.weldx.security.enterprise.identitystore.IdentityStore$635317201$Proxy$_$$_WeldClientProxy.validate(Unknown Source)
> at org.glassfish.soteria.cdi.DefaultIdentityStoreHandler.validate(DefaultIdentityStoreHandler.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ELY-1667) Trace logging in SSLUtils
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1667:
-------------------------------------
Summary: Trace logging in SSLUtils
Key: ELY-1667
URL: https://issues.jboss.org/browse/ELY-1667
Project: WildFly Elytron
Issue Type: Bug
Components: SSL
Affects Versions: 1.6.0.Final
Reporter: Martin Choma
Assignee: Justin Cook
Fix For: 1.6.1.Final, 1.7.0.CR1
Check Trace logging of ssl context creation. How I read code logging should apply after throw expression. That wouldn never happen. Also there is another throw of exception with SSLUtils::throwIt.
{code:java|title=org.wildfly.security.ssl.SSLUtils}
// now return a factory that will return the best match is can create.
final String[] supportedProtocols = protocolSelector.evaluate(preferredProviderByAlgorithm.keySet().toArray(NO_STRINGS));
if (supportedProtocols.length > 0) {
return () -> {
for (String protocol : supportedProtocols) {
List<Provider> providerList = preferredProviderByAlgorithm.getOrDefault(protocol, Collections.emptyList());
for (Provider provider : providerList) {
try {
return SSLContext.getInstance(protocol, provider);
} catch (NoSuchAlgorithmException ignored) {}
}
}
throw ElytronMessages.log.noAlgorithmForSslProtocol();
};
}
if (log.isTraceEnabled()) {
log.tracef("No %s provided by providers in %s: %s", SERVICE_TYPE, SSLUtils.class.getSimpleName(), Arrays.toString(providerSupplier.get()));
}
return SSLUtils::throwIt;
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ELY-1666) Update AcmeClientSpi.changeAccountKey() to no longer send the newKey once the new ACME v2 changes are in production
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1666:
-------------------------------------
Summary: Update AcmeClientSpi.changeAccountKey() to no longer send the newKey once the new ACME v2 changes are in production
Key: ELY-1666
URL: https://issues.jboss.org/browse/ELY-1666
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Reporter: Farah Juma
Assignee: Farah Juma
Fix For: 1.6.1.Final, 1.7.0.CR1
For ELY-1629, {{AcmeClientSpi.changeAccountKey()}} was updated to include both {{newKey}} and {{oldKey}} in the inner payload for the account key change request to prepare for the ACME v2 key rollover [breaking change|https://community.letsencrypt.org/t/acme-v2-draft-13-compliant-key...]. Currently, specifying both works fine since Let's Encrypt's staging server will expect {{oldKey}} and ignore {{newKey}} and Let's Encrypt's production server will expect {{newKey}} and ignore {{oldKey}}. However, once the new ACME v2 key rollover changes are available in Let's Encrypt's production server on Aug. 23rd, we can update this method to only include the {{oldKey}} in the inner payload.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ELY-1653) JDK 11 Support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1653?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1653:
----------------------------------
Fix Version/s: 1.7.0.CR1
(was: 1.6.1.Final)
> JDK 11 Support
> --------------
>
> Key: ELY-1653
> URL: https://issues.jboss.org/browse/ELY-1653
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Fix For: 1.7.0.CR1
>
>
> I suspect this will likely take three / four steps: -
> # Convert he project to a multi-release built using Java 9
> # Eliminate the use of APIs in sun.misc and sun.reflect in the Java 9 variant
> # Ensure the project can be build on JDK 11
> This final step may not be achievable in the short term until we can drop support for JDK 8 but by moving to the Java 9 MR jar our jar should be compatible on Java 10 and 11 as well. We may want to define a PR run that builds on Java 9 but tests in Java 11, this would mean the testsuite at least needs to be buildable on Java 11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months