Permissions on temporary destinations (JBMESSAGING-994)

[sergeypk]

Currently, temporary destinations are assigned the default security configuration when they are created. This means that if I log in as a user who has less permissions than required by the default security configuration, and create a temporary destination, I can't access it afterwards.

Something should be done about it. Here are some options:

1) Skip permission checks on temporary destinations. Bad because there's a possibility of DoS attacks if someone guesses the temp destination name.

2) Disallow creating temporary destinations that the logged-in user will not be able to use - doesn't solve the actual problem.

3) Have some configuration mechanism for temporary destination permissions - not sure where it would go, to make it sufficiently flexible.

Any ideas?

[timfox]

"sergeypk" wrote:
Currently, temporary destinations are assigned the default security configuration when they are created. This means that if I log in as a user who has less permissions than required by the default security configuration, and create a temporary destination, I can't access it afterwards.

When you say "access" do you mean send messages to, or consume messages from?

Something should be done about it. Here are some options:

1) Skip permission checks on temporary destinations. Bad because there's a possibility of DoS attacks if someone guesses the temp destination name.

Not a good idea.

But the issue is not about guessing the temp destination name.

A valid use case would be sending messages to a topic with JMSReplyTo set, and only some users have rights to respond on the reply to destination.

In this case no guessing is necessary.

2) Disallow creating temporary destinations that the logged-in user will not be able to use - doesn't solve the actual problem.

Which user are you referring to? The creator of the temp destination, or the consumer?

3) Have some configuration mechanism for temporary destination permissions - not sure where it would go, to make it sufficiently flexible.

Temp destination security could be overridden in the connection factory. That's where the other temp destination attributes are overridden.

[sergeypk]

"timfox" wrote:
When you say "access" do you mean send messages to, or consume messages from?

I have only tried consuming, but I don't have any reason to believe that sending would be different. Using SecurityTest settings, for example, if I login as user guest, and call createTemporaryQueue, the queue has default permissions requiring role "def" to read/write to it (verified under a debugger). User guest doesn't have role "def".

"timfox" wrote:

2) Disallow creating temporary destinations that the logged-in user will not be able to use - doesn't solve the actual problem.

Which user are you referring to? The creator of the temp destination, or the consumer?

The creator.

"timfox" wrote:

3) Have some configuration mechanism for temporary destination permissions - not sure where it would go, to make it sufficiently flexible.

Temp destination security could be overridden in the connection factory. That's where the other temp destination attributes are overridden.

But this means that different users will all use the same temp destination security? Is this ok? Shouldn't the temp destination permissions be configurable on a per-user basis?

[timfox]

"sergeypk" But this means that different users will all use the same temp destination security? Is this ok? Shouldn't the temp destination permissions be configurable on a per-user basis?[/quote wrote:

Why?

I am struggling to understand what the real issue is here...

[timfox]

But this means that different users will all use the same temp destination security? Is this ok? Shouldn't the temp destination permissions be configurable on a per-user basis?

Why?

I am struggling to understand what the real issue is here...

Can you summarise?

[sergeypk]

Suppose we have user joe and he wants to send a message to some destination and receive a reply. So he does createConnection("joe", "joespassword") and then creates a temporary queue and sends a message to some queue with JMSReplyTo set to the temporary queue.

In the ideal world, I would probably want to configure the temporary queue so that only the intended recipient can write to it and only joe can read from it.

But what if then we have user jane trying to send a message of her own to some destination totally unrelated to that of joe's, and she wants to use a temporary queue as well? How would we configure temporary queue permissions to be adequate for both cases if both users are to use the same connection factory?

[timfox]

Can't we just add roles "temporary-queue-readers" and "temporary-queue-writers", set that as the security on the connection factory (or just the default security), then make sure joe and jane have the appropriate roles?

[sergeypk]

Yes, this will work. It seems quite inflexible to me though (a user can either access any temporary queue or none at all), but it's better than nothing.

[timfox]

"sergeypk" wrote:
Yes, this will work. It seems quite inflexible to me though (a user can either access any temporary queue or none at all), but it's better than nothing.

How is this inflexible?

What is the use case for someone being able to read/write from some temporary destinations rather than others? I don't see it yet.

Even if you wanted the ability to specify different security configuration on a per temporary queue basis, how would you specify this?

This would have to be done programmatically by the creator of the temp destination. What API would they use?

I am still struggling to see what the point of this is.

[sergeypk]

"timfox" wrote:
What is the use case for someone being able to read/write from some temporary destinations rather than others? I don't see it yet.

Ok, me neither, so I'll implement the solution we agreed on, specifying temp destination security in the connection factory.

[thomasra]

There are many scenarios where this is applicable, basically it involves all blocking/synchronous request/response use cases where the calling party (the "client") is not configured to have a permanent destination for response. Using temp destinations allows an otherwise non-"connected" JMS client to receive responses only destined for itself (queries etc).

I agree with sergey about temp destinations being more targeted to the actual case: a user that creates a temp destination should have full access to it, but then there is the question of that user granting further rights so someone else can actually use it (for replies etc).

Regarding something more specific: the QueueRequestor/TopicRequestor classes already know which destination ("X") the client is communicating with, and creates an (for the client) unnamed ("Y") destination for replies. This use case could be much smarter and actually create a temp destination ("Y") which the client (and only the client) is allowed to read from, and the role which is allowed to read from "X" is granted the right to write to "Y"?

[thomasra]

To repeat a previous posting with precise wording from the spec:

(4.4.3)
...only their own connection is allowed to create MessageConsumers for them....

So basically using the same connectionfactory is not enough...

...and since the specification seems to ignore Producers but mentions "ReplyTo" as a common use case I would assume they mean that anyone can produce messages on a temp destination?

[timfox]

"thomasra" wrote:
To repeat a previous posting with precise wording from the spec:

(4.4.3)
...only their own connection is allowed to create MessageConsumers for them....

So basically using the same connectionfactory is not enough...

No, this is already implemented (long time ago), try creating a consumer on a temp destination you didn't create - you won't be able to. This is isn't configured using security.

...and since the specification seems to ignore Producers but mentions "ReplyTo" as a common use case I would assume they mean that anyone can produce messages on a temp destination?

Right.

So, to clarify this:

a) Only the creating connection of the temp queue can create a consumer on it. This has been implemented for ages, it's part of the JMS spec, and we wouldn't have got JMS 1.1 compliance in Sep 2005 without doing this.

b) The JMS spec puts no restrictions on who can write (send messages to) a temp queue. Currently in our implementation temp queues are governed by the standard default destination security config.

c) As has been suggeted, we *could* allow the creator of the temp queue to specify programmaticall additionaly security for the temp queue at creation time. I agree this may be useful but is a "nice to have".
I also repeat my earlier question of what API they would use to specify this security? This would also be non JMS so it makes their code non portable.

[thomasra]

Hm. But you are forgetting that in addition to what you are saying the user also needs roles defined for reading from everything, which isn't really that useful. Why allow something to be created that you yourself cannot access? It should be consistently one or the other.

A temp destination created by a client cannot be consumed from unless that client has a read role on everything (since the temporary destination roles aren't covered by any specific security configuration property).

[thomasra]

Yes, it is outside the spec, but this is more a case of making something work as intended. It cannot be intended that the creator of a temp destination should have read access to _everything_ in order to be able to consume from the temp dest.