[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-28:
-------------------------------------
[~fnigro] Yes, there is most likely issue with non-heap memory allocation.
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Francesco Nigro
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: sosreport-rvaisdebug.asd-20180807101658.tar.xz
>
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-67) [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-67?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-67:
-------------------------------------
Yes, there is sent mix of normal and large messages.
> [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-67
> URL: https://issues.jboss.org/browse/WFWIP-67
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
>
> *Scenario:*
> Nodes A and B are in cluster. Destinations InQueue and OutQueue are deployed on them.
> MDBs are deployed on node C and D. These MDBs read messages from InQueue of nodes A, B and sends them to OutQueue on A and B.
> Nodes A,B are running Artemis 1.5. Nodes C,D are using Artemis 2.6.
> # Client sends messages to InQueue on node A
> # MDBs on nodes C,D read messages from remote InQueue and send them to remote OutQueue on nodes A,B
> # During processing of messages nodes A and C are killed
> # Client reads messages from OutQueue on node B.
> *Issue*
> At the end of the test, client is not able to read message
> {code}
> java.lang.IndexOutOfBoundsException: readerIndex(9) + length(128) exceeds writerIndex(133): UnpooledDuplicatedByteBuf(ridx: 9, widx: 133, cap: 606, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 606, cap: 606))
> at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1405)
> at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1392)
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872)
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:880)
> at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649)
> at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:183)
> at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:171)
> at org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:158)
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:69)
> at org.apache.activemq.artemis.reader.TextMessageUtil.readBodyText(TextMessageUtil.java:37)
> at org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:112)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:224)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:132)
> at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:151)
> at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10054) [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10054?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10054:
------------------------------------
I am not sure about this one.
Artemis Core API is supported, that's correct. But ActiveMQJMSClient is not part of the Core API.
It is part of Artemis JMS client library. It is a non-standard, non-portable way to instantiate JMS resources.
Application should use JNDI to lookup JMS resources and not used broker-specific library.
I am not sure if our support extends to this class.
[~bilge] Could you please confirm? We need to know the support for using non-standard ActiveMQJMSClient library in client application.
If it is not supported, it is ok that this code breaks.
If it is supported, we need to fix such a regression. We should also revisit the decision to support it as there is no good reason for Java EE applications to use broker-specific way to instantiate JMS resources when there is standard way to do so using JNDI.
> [Artemis 2.x Upgrade] Client is not able to instantiate destinations by names
> -----------------------------------------------------------------------------
>
> Key: WFLY-10054
> URL: https://issues.jboss.org/browse/WFLY-10054
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq
>
> Having queue defined as follows
> {code:xml}
> <jms-queue name="InQueue" entries="jms/queue/InQueue java:jboss/exported/jms/queue/InQueue" durable="true"/>
> {code}
> Client is instantiating it directly using its name.
> {code:title=Client}
> HashMap<String, Object> map = new HashMap<String, Object>();
> map.put("host", hostName);
> map.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
> map.put("port", httpPort);
> TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
> try {
> ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration);
> Queue orderQueue = ActiveMQJMSClient.createQueue("InQueue");
> connection = cf.createConnection();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(orderQueue);
> connection.start();
> ...
> {code}
> Client is not able to send messages to, because {{session.createProducer(orderQueue)}} throws following exception
> {code}
> javax.jms.InvalidDestinationException: Destination InQueue does not exist
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createProducer(ActiveMQSession.java:326)
> {code}
> This is regression against EAP 7.1.0
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2867) [Guided Rule] You have to reopen rule to load dependent enums
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2867?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-2867:
--------------------------------------
This will teach me to touch old code!
> [Guided Rule] You have to reopen rule to load dependent enums
> -------------------------------------------------------------
>
> Key: DROOLS-2867
> URL: https://issues.jboss.org/browse/DROOLS-2867
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Labels: drools-tools, regression
> Attachments: Screenshot from 2018-08-08 15-13-14.png, Screenshot from 2018-08-08 15-14-00.png, Screenshot from 2018-08-08 15-14-50.png
>
>
> Imagine you have data object like
> {code:java}
> package com.myspace.new_one_project;
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private java.lang.String name2;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.String getName2() {
> return this.name2;
> }
> public void setName2(java.lang.String name2) {
> this.name2 = name2;
> }
> public Person(java.lang.String name, java.lang.String name2) {
> this.name = name;
> this.name2 = name2;
> }
> }
> {code}
> and enumeration
> {code}
> 'Person.name' : ['a','b']
> 'Person.name2[name=a]' : ['c', 'd']
> {code}
> Then create constraint like
> !Screenshot from 2018-08-08 15-13-14.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-00.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-50.png|thumbnail!
> Notice the constraint for name2 field doesn't offer enums 'c' and 'd'. If you save and reopen the rule 'c' and 'd' will be offered. They should be offered without reopening the rule.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2867) [Guided Rule] You have to reopen rule to load dependent enums
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2867?page=com.atlassian.jira.plugi... ]
Toni Rikkola edited comment on DROOLS-2867 at 8/9/18 7:38 AM:
--------------------------------------------------------------
This will teach me to touch old code! Or not to touch.
was (Author: rikkola):
This will teach me to touch old code!
> [Guided Rule] You have to reopen rule to load dependent enums
> -------------------------------------------------------------
>
> Key: DROOLS-2867
> URL: https://issues.jboss.org/browse/DROOLS-2867
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Labels: drools-tools, regression
> Attachments: Screenshot from 2018-08-08 15-13-14.png, Screenshot from 2018-08-08 15-14-00.png, Screenshot from 2018-08-08 15-14-50.png
>
>
> Imagine you have data object like
> {code:java}
> package com.myspace.new_one_project;
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private java.lang.String name2;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.String getName2() {
> return this.name2;
> }
> public void setName2(java.lang.String name2) {
> this.name2 = name2;
> }
> public Person(java.lang.String name, java.lang.String name2) {
> this.name = name;
> this.name2 = name2;
> }
> }
> {code}
> and enumeration
> {code}
> 'Person.name' : ['a','b']
> 'Person.name2[name=a]' : ['c', 'd']
> {code}
> Then create constraint like
> !Screenshot from 2018-08-08 15-13-14.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-00.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-50.png|thumbnail!
> Notice the constraint for name2 field doesn't offer enums 'c' and 'd'. If you save and reopen the rule 'c' and 'd' will be offered. They should be offered without reopening the rule.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-67) [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-67?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on WFWIP-67:
--------------------------------------
Are there large messages here ?
> [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-67
> URL: https://issues.jboss.org/browse/WFWIP-67
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
>
> *Scenario:*
> Nodes A and B are in cluster. Destinations InQueue and OutQueue are deployed on them.
> MDBs are deployed on node C and D. These MDBs read messages from InQueue of nodes A, B and sends them to OutQueue on A and B.
> Nodes A,B are running Artemis 1.5. Nodes C,D are using Artemis 2.6.
> # Client sends messages to InQueue on node A
> # MDBs on nodes C,D read messages from remote InQueue and send them to remote OutQueue on nodes A,B
> # During processing of messages nodes A and C are killed
> # Client reads messages from OutQueue on node B.
> *Issue*
> At the end of the test, client is not able to read message
> {code}
> java.lang.IndexOutOfBoundsException: readerIndex(9) + length(128) exceeds writerIndex(133): UnpooledDuplicatedByteBuf(ridx: 9, widx: 133, cap: 606, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 606, cap: 606))
> at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1405)
> at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1392)
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872)
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:880)
> at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649)
> at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:183)
> at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:171)
> at org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:158)
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:69)
> at org.apache.activemq.artemis.reader.TextMessageUtil.readBodyText(TextMessageUtil.java:37)
> at org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:112)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:224)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:132)
> at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:151)
> at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2867) [Guided Rule] You have to reopen rule to load dependent enums
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2867?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-2867:
--------------------------------------
Assignee: Toni Rikkola (was: Michael Anstis)
> [Guided Rule] You have to reopen rule to load dependent enums
> -------------------------------------------------------------
>
> Key: DROOLS-2867
> URL: https://issues.jboss.org/browse/DROOLS-2867
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Labels: drools-tools, regression
> Attachments: Screenshot from 2018-08-08 15-13-14.png, Screenshot from 2018-08-08 15-14-00.png, Screenshot from 2018-08-08 15-14-50.png
>
>
> Imagine you have data object like
> {code:java}
> package com.myspace.new_one_project;
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private java.lang.String name2;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.String getName2() {
> return this.name2;
> }
> public void setName2(java.lang.String name2) {
> this.name2 = name2;
> }
> public Person(java.lang.String name, java.lang.String name2) {
> this.name = name;
> this.name2 = name2;
> }
> }
> {code}
> and enumeration
> {code}
> 'Person.name' : ['a','b']
> 'Person.name2[name=a]' : ['c', 'd']
> {code}
> Then create constraint like
> !Screenshot from 2018-08-08 15-13-14.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-00.png|thumbnail!
> Then update it like:
> !Screenshot from 2018-08-08 15-14-50.png|thumbnail!
> Notice the constraint for name2 field doesn't offer enums 'c' and 'd'. If you save and reopen the rule 'c' and 'd' will be offered. They should be offered without reopening the rule.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3963) Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3963?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek edited comment on WFCORE-3963 at 8/9/18 7:11 AM:
---------------------------------------------------------------
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///$\{jboss.server.config.dir\}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///$\{jboss.server.config.dir\}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="*algorithm_name*"/>
</login-module>
</authentication>{quote}
was (Author: jondruse):
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///$\{jboss.server.config.dir\}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///$\{jboss.server.config.dir\}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
> Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3963
> URL: https://issues.jboss.org/browse/WFCORE-3963
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: Regression
> Fix For: 6.0.0.Alpha5
>
> Attachments: standalone-for-node01.xml, standalone2.xml
>
>
> Fix https://issues.jboss.org/browse/WFCORE-3826 fixes anonymous authentication but breaks authenticated mode (for example PLAIN mode with username/password). See https://issues.jboss.org/browse/JBEAP-14647 for more details.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3963) Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3963?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek edited comment on WFCORE-3963 at 8/9/18 7:10 AM:
---------------------------------------------------------------
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///$\{jboss.server.config.dir\}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///$\{jboss.server.config.dir\}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
was (Author: jondruse):
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///\${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///\${jboss.server.config.dir}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
> Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3963
> URL: https://issues.jboss.org/browse/WFCORE-3963
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: Regression
> Fix For: 6.0.0.Alpha5
>
> Attachments: standalone-for-node01.xml, standalone2.xml
>
>
> Fix https://issues.jboss.org/browse/WFCORE-3826 fixes anonymous authentication but breaks authenticated mode (for example PLAIN mode with username/password). See https://issues.jboss.org/browse/JBEAP-14647 for more details.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months