Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Repudiation attacks to Artemis: we currently audit connections, we need to add some kind of per-message auditing. Maybe also include the sender on the message for non-repudiation in something like the DLQ UI
  • Spoofing attacks on sending/consuming messages and creating addresses: we can leverage Artemis controls to secure addresses to only valid users
  • DoS Input attacks, such as a poison message: this needs more investigation. Initial analysis makes this look very difficult. Could lower Artemis "retry" on failed messages to partially mitigate.
  • DoS Output attacks, such as a slow consumer: we can use built in Artemis tools, such as last-value queue, message expiration, and killing the consumer's connection to mitigate DoS output attacks on Artemis
  • DoS Input attacks on DDF, such as a very large message that is hard to consume: we can validate input before processing to mitigate this threat

Artemis Thread

...

Modeling Follow Up and Next Steps (8/30): 

Outcome: we'll look into the JAASLoginModule and Interceptor extensibility points provided by Artemis. The hope is that we can implement the JAASLoginModule and Interceptor capabilities to join the Principal and the Message so that we can have authentication and authorization information on a per-message basis. This will aid in authorizing catalog framework interactions.

...

The idea of using Camel in front of Artemis and tying our DDF security in before even hitting Artemis was brought up as well.

Artemis Interceptor Prototyping Notes:

Adding an Artemis interceptor allows the for interception of packets entering and exiting the broker. Information regarding the remote connection used in the packet transmission is also provided via the interceptor. Depending on what protocol is being used for message communication, a different kind of interceptor is required to be implemented (e.g. AmqpInterceptor for AMQP, Interceptor for Core).

When debugging through the Interceptor over the Core protocol, I noticed there was very minimal security information inside both the Packet and RemotingConnection objects. The Packet only had little information regarding the message, the address of the message, and other small details depending on the type of packet. No security information was present in the Packet. The RemotingConnection had low level details about the connection, including the IP of the broker and the protocol used, but no security information was present regarding the connection. The interface of the RemotingConnection object however does expose a getSubject method, but its implementation just returns null. A pull request to Artemis would be necessary in order to implement getSubject and attach the subject to the Packet.