How to use custom security with JMS destination rule in WildFly

[valsaraj007]

How to use custom security with JMS destination rule in WildFly.

By default:

<security-settings>

                        <security-setting match="#">

                            <permission type="send" roles="guest"/>

                            <permission type="consume" roles="guest"/>

                            <permission type="createNonDurableQueue" roles="guest"/>

                            <permission type="deleteNonDurableQueue" roles="guest"/>

                        </security-setting>

                    </security-settings>

                    <address-settings>

                        <address-setting match="#">

                            <dead-letter-address>jms.queue.DLQ</dead-letter-address>

                            <expiry-address>jms.queue.ExpiryQueue</expiry-address>

                            <max-delivery-attempts>6</max-delivery-attempts>

                            <max-size-bytes>10485760</max-size-bytes>

                            <page-size-bytes>2097152</page-size-bytes>

                            <message-counter-history-day-limit>10</message-counter-history-day-limit>

                            <redistribution-delay>1000</redistribution-delay>

                        </address-setting>

                    </address-settings>

                        ....   Added queue

                    <jms-queue name="testQ">

                            <entry name="queue/testQ"/>

                            <entry name="java:/jms/queue/testQ"/>

                        </jms-queue>

                    <jms-queue name="testQDLQ">

                            <entry name="queue/testQDLQ"/>

                            <entry name="java:/jms/queue/testQDLQ"/>

                        </jms-queue>

I want ti use separate security domain & role for a queue and separate DLQ for that.

eg: Queue names testQ & DLQ named testQDLQ. They are restricted by security domain named appSecDom & role testQWriteRole& testQReadRole.

[jbertram]

The message broker can only be configured with one security domain.

However, you can define an arbitrary number of roles and maps those roles to specific permission and address combinations.  For example, given the "testQ" and "testQDLQ" queues and "testQWriteRole" and "testQReadRole" roles you have defined you can have the following:

<security-settings>
    <security-setting match="jms.queue.testQ">
        <permission type="send" roles="testQWriteRole"/>
    </security-setting>
    <security-setting match="jms.queue.testQDLQ">
        <permission type="consume" roles="testQReadRole"/>
    </security-setting>
</security-settings>

Does that answer your question?

[valsaraj007]

I added the above configuration:

1. <security-settings> 
2.     <security-setting match="jms.queue.testQ"> 
3.         <permission type="send" roles="testQWriteRole  testQRole"/> 
4.     </security-setting> 
5.     <security-setting match="jms.queue.testQDLQ"> 
6.         <permission type="consume" roles="testQRole"/> 
7.     </security-setting> 
8. </security-settings> 

I needed multiple roles to allow sending messages, so added them separate by <space>.

[jbertram]

Permissions and roles are part of authorization.  Usernames are passwords are part of authentication.  These two things are related but separate.

If you're receiving "Unable to validate user" then my first thought is that you're submitting the wrong username and/or password.  Can you confirm that your credentials in jboss-ejb3.xml are correct?  Are you able to successfully use those credentials from other messaging clients?

[valsaraj007]

Yes, it is working from others. I wonder whether the username/password is correct but referring wrong security domain?

It is referred in HornetQ as <security-domain>appLDAP</security-domain>. It is the configured name, should I use JNDI path instead like java:/../appLDAP?

[jbertram]

I think that if it couldn't find the security domain then it would throw a different kind of error as the broker wouldn't even be able to complete authentication.  Try using the default security domain configuration to see if that works.

[valsaraj007]

Yes, it worked.

[jbertram]

I'm not sure what else to tell you at this point.  You have a configuration that works, and when you change the configuration it doesn't work.  That suggests to me that something is broken in the new configuration that doesn't work.  The broken piece could be in the configuration of "appLDAP" on Wildfly or on the LDAP server itself.  Either way, those pieces are outside my realm of expertise.