[
https://issues.apache.org/jira/browse/ARTEMIS-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900734#comment-17900734
]
Olaf Gustav commented on ARTEMIS-5163:
--------------------------------------
To send an LWT message, the client's authorization data (send permission to the
will topic) must be taken into account. Using a broker identity would mean that
one is needed for each connected client (with LWT settings). I could not find a
similar feature in the code. All identities seem to be defined in corresponding
configuration files.
An alternative would be to ignore authentication, since the connected client
has already been authenticated. Then, only authorization data, represented by a
*javax.security.auth.Subject* object, has to be stored. A proposal for
implementation:
# Client connects successfully (is authenticated)
## get current authorization data (Subject) by using the client's identity and
store it in MQTTSessionState
## update the stored Subject each time the
HierarchicalRepositoryChangeListener.onChange() method is called (only possible
if client is still connected, because its identity is needed)
# Send LWT message
## skip authentication
## get stored Subject to check permissions
## remove stored Subject after sending LWT message
This approach has some advantages:
* no authentication/authorization cache needed
* no separate broker identities needed
* send permissions are strictly considered
> Artemis fails to send mqtt will message using mutual TLS
> --------------------------------------------------------
>
> Key: ARTEMIS-5163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5163
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
> Affects Versions: 2.31.2, 2.33.0, 2.38.0
> Reporter: Olaf Gustav
> Priority: Major
>
> As discussed in the user mailing list, the MQTT broker fails to sent the
> provided will message when using mutual TLS.
> +set-up for testing:+
> * ActiveMQ Artemis 2.33 as MQTT broker
> * Artemis runs on jdk-21
> * clients are authenticated using mutual TLS
> * certificate DN is used to map to a user and eventually to the configured
> roles
> +issue:+
> During testing we discovered, that the provided will message is not sent as
> expected. We got the following error messages:
> {code:none}
> WARN [org.apache.activemq.artemis.core.server] AMQ222216: Security problem
> while authenticating: AMQ229031: Unable to validate user from /
> 127.0.0.1:51770. Username: null; SSL certificate subject DN: unavailable
> ERROR [org.apache.activemq.artemis.core.protocol.mqtt] AMQ834007:
> Authorization failure sending will message: AMQ229031: Unable to validate
> user from / 127.0.0.1:51770. Username: null; SSL certificate subject DN:
> unavailable
> {code}
> I did some research in the code base. The class
> *org.apache.activemq.artemis.core.remoting.CertificateUtil* retrieves the
> certificate subject DN based on the actual client certificate provided by an
> existing connection. When trying to send a mqtt will message, there is no
> connection to the client anymore. Consequently, the broker fails to get the
> DN. Since the subject DN serves as the key in the authentication cache
> ({*}org.apache.activemq.artemis.core.security.impl. SecurityStoreImpl{*}),
> the will message fails to be checked against access permissions.
> As a workaround, I used the RemotingConnection.clientID as authentication
> cache key instead of the DN. That works as long as the parameter
> *security-invalidation-interval* is properly defined, that means
> {{{}security-invalidation-interval >> sessionExpiryInterval{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
