[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1648:
------------------------------
Steps to Reproduce:
- Run server and jboss-cli client with FIPS java
- ./jboss-cli.sh \
-c \
-Dwildfly.config.url=file:///home/mchoma/task/ELY-1648/wildfly-config.xml \
--connect
{code}
/subsystem=elytron/key-store=key-store-name_test-server-ssl-context:add(type=PKCS11, credential-reference={clear-text => pass123+})
/subsystem=elytron/key-manager=key-manager-name_test-server-ssl-context:add(key-store=key-store-name_test-server-ssl-context, credential-reference={clear-text => pass123+})
/subsystem=elytron/key-store=trust-store-name_test-server-ssl-context:add(type=PKCS11, credential-reference={clear-text => pass123+})
/subsystem=elytron/trust-manager=trust-manager-name_test-server-ssl-context:add(key-store=trust-store-name_test-server-ssl-context)
/subsystem=elytron/server-ssl-context=test-server-ssl-context:add(key-manager=key-manager-name_test-server-ssl-context, cipher-suite-filter="TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA", trust-manager=trust-manager-name_test-server-ssl-context, protocols=[TLSv1.1], need-client-auth=true)
/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=test-server-ssl-context)
reload
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
reload
{code}
Exception thrown from CLI trying to reconnect
was:
- ./standalone.sh
- run CLI with FIPS PKCS11 java
{code}
./jboss-cli.sh \
-c \
-Dwildfly.config.url=file:///from/attachment/cli-test-wildfly-config.xml \
--connect \
:read-attribute\(name=server-state\)
{code}
> 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
> Attachments: java.security
>
>
> 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/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1648) FIPS NoSuchAlgorithmException: JKS KeyStore not available when trustmanager SunX509
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1648?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1648:
-----------------------------------
You are right, following reproducer I was not able to see error. I have updated reproducer. Please give a try.
> 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
> Attachments: java.security
>
>
> 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/...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFLY-10837:
----------------------------------
Priority: Blocker (was: Major)
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Blocker
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10837) IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-10837?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFLY-10837:
---------------------------------------
I'm increasing the priority, as this issue affects the configuration backward compatibility (see [my previous comment|https://issues.jboss.org/browse/WFLY-10837?focusedCommentId=13635...] on how to reproduce).
> IIOP subsystem requires port binding to be defined which was not necessary in prior WFLY versions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10837
> URL: https://issues.jboss.org/browse/WFLY-10837
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Fix For: 14.0.0.Final
>
>
> If the {{standalone-*.xml}} configuration defines to use IIOP subsystem but it does not defines the port binding element
> {code}
> <orb socket-binding="iiop"/>
> {code}
> The server starts with error
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.iiop-openjdk.orb-service: org.jboss.msc.service.StartException in service jboss.iiop-openjdk.orb-service: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYIIOP0115: No IIOP socket bindings have been configured
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:109)
> ... 8 more
> {code}
> The attribute of the {{socket-binding}} in the model is not defined as {{required}}.
> {code}
> "socket-binding" => {
> "type" => STRING,
> "description" => "The name of the socket binding configuration that specifies the ORB port.",
> "attribute-group" => "orb",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
> Up to that declaring the iiop socket binding was not necessary in WildFly 13.0.0.Final. Could that be a backward compatibility problem too?
> Up to that
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-2254:
-------------------------------------------
Fix Version/s: 7.13.0.Final
(was: 7.12.0.Final)
> Automate .proto files rebuild in pom.xml
> ----------------------------------------
>
> Key: DROOLS-2254
> URL: https://issues.jboss.org/browse/DROOLS-2254
> Project: Drools
> Issue Type: Task
> Components: tools
> Affects Versions: 7.5.0.Final
> Reporter: Dmitry Volodin
> Assignee: Dmitry Volodin
> Priority: Minor
> Fix For: 7.13.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2810) Kie-dmn OSGI feature can not be installed
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2810?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-2810:
-------------------------------------------
Fix Version/s: 7.13.0.Final
(was: 7.12.0.Final)
> Kie-dmn OSGI feature can not be installed
> -----------------------------------------
>
> Key: DROOLS-2810
> URL: https://issues.jboss.org/browse/DROOLS-2810
> Project: Drools
> Issue Type: Bug
> Components: integration
> Reporter: Jiri Petrlik
> Assignee: Jiri Petrlik
> Fix For: 7.13.0.Final
>
>
> It is not possible to install kie-dmn OSGI feature. Installation fails with following exception:
> Unable to resolve org.kie.dmn.core/7.10.0.201807310901: missing requirement [org.kie.dmn.core/7.10.0.201807310901] osgi.wiring.package; filter:="(osgi.wiring.package=org.drools.model)"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-11073) Support hex encoding in jdbc-realm for elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-11073?page=com.atlassian.jira.plugin... ]
Jan Kalina moved WFCORE-4128 to WFLY-11073:
-------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-11073 (was: WFCORE-4128)
Component/s: Security
(was: Security)
Affects Version/s: (was: 5.0.0.Alpha7)
> Support hex encoding in jdbc-realm for elytron
> ----------------------------------------------
>
> Key: WFLY-11073
> URL: https://issues.jboss.org/browse/WFLY-11073
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: elytron
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-11073) Support hex encoding in jdbc-realm for elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-11073?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-11073:
------------------------------
Component/s: Documentation
> Support hex encoding in jdbc-realm for elytron
> ----------------------------------------------
>
> Key: WFLY-11073
> URL: https://issues.jboss.org/browse/WFLY-11073
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation, Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: elytron
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months