Artemis Security Design Discussion

Artemis Security Questions:

Q?	A.
How do we pass the subject through Artemis? Some kind of ID? SAML token in the message header?	Probably some kind of GUID that we can map to an assertion in a cache in Artemis
2. How do we authenticate? Artemis supports using a JAAS login module. Do we tie it to the Karaf JAAS or LDAP or do we tie it in at a higher level? Would be nice to not have to reconfigure Artemis every time we decide to switch authentication methods	Likely a JAAS Login Module that can connect with the DDF STS. This abstracts the realm away from Artemis and will try all configured DDF realms
3. Do we need Artemis roles on queues/topics to be configurable?	Probably not, we can use good hierarchical namespacing to prevent the need to reconfigure roles
4. Do we need attribute based message filtering?	Probably not
5. How do we map roles from DDF to the roles that Artemis uses?	We can probably specify the roles that Artemis needs as a part of the authorization realm configuration
6. How do we tie in our security information to every message? We need to be able to add some kind of identifying information to every message as it comes into the broker
7. Can Apache ignite solve our concerns for caching security info?

Initial Artemis discussion notes (8/8):

Two options for authentication:

1) Does Artemis have a pluggable point that we could implement something like Servlet filters (need more information on how this is mutually exclusive with #2 and what benefits it would give us)
2) Use JAAS to plug into DDF (leaning toward this solution, can plug into the STS, abstracts away other JAAS realms)

How to maintain subject?

SAML assertion? Sounds nice, but since queues and topics can be public, this could be accidentally shared out
probably leaning toward a a guid that can map to a cache in Artemis that only DDF is allowed to access

We still need a way to attach security "stuff" (assertion, guid that maps to assertion, etc) to each message. Up to now, we've only talked about authenticating every connection; we need a way to take the authentication/authorization that happens at the connection and attach it to every single message

Possibly could use Apache ignite to store the cache assertion information, this needs more research

Artemis Threat Modelling Discussion (8/9):

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.

Questions that we need answered:

1) At what point do we lose credential/authentication info? (We want to have access to a message before we lose this info)

2) What's the closest point to the authentication/credential info that we can intercept the message?

Concerns: If there's no kind of extensibility where we can maintain access to the Principal and message, we would have make a call to authenticate/authorize every individual message.

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 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 or no security information inside both the Packet and RemotingConnection objects. The Packet only had information regarding the message, the address of the message, and other small details of the packet depending on its type. 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.

Decision

Decided to contribute an improvement to Artemis upstream.

https://github.com/apache/activemq-artemis/commit/86a2cad12ac77cc50ff5841c87d5d15865f983c3

Artemis security plugins can now be developed downstream of DDF.