-
15. Re: Permissions on temporary destinations (JBMESSAGING-994)
"thomasra" wrote:
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.
Right, and that is why Sergey is adding security overrides on the connection factory as discussed, which will take effect for temp queues. -
16. Re: Permissions on temporary destinations (JBMESSAGING-994)
As I say, if you can come up with a better solution, go for it.
It's just I haven't heard one yet. -
17. Re: Permissions on temporary destinations (JBMESSAGING-994)
Just a brief question: if, as you say, you handle the issue of protecting a temp destination from being consumed by anyone other than the original connection _outside_ any security code, then why bother using it when you _are_ within the same connection?
Couldn't the temp destination include metadata describing the original connectionid/sessionid, and just check that consumers belong to the same id? No other checks need to be made, and no more configuration needs to be extended on the connectionfactory? -
18. Re: Permissions on temporary destinations (JBMESSAGING-994)
To sum it all up: I don't think rolebased security is appropriate for temp destinations at all (neither consuming nor producing), the only restriction needed is the one related to consumers, which isn't security code.
-
19. Re: Permissions on temporary destinations (JBMESSAGING-994)
"thomasra" wrote:
To sum it all up: I don't think rolebased security is appropriate for temp destinations at all (neither consuming nor producing), the only restriction needed is the one related to consumers, which isn't security code.
Well, yes, that is one option, we just drop role based security altogether for temp destinations and just have the current check which verifies that consumers can only be created by the connection that created the temp dest. (Easy option).
But most of this thread is about how do we configure security for users who *write* (i.e. send messages) to the destination - this is what we are really discussing.
Here is the use case:
User creates temp reply queue and sends a message to a topic with the JMSReplyTo header set.
The message is received by many subscribers, but only some of them are allowed to reply.
E.g. it might be a news feed and only "gold subcribers" can reply. We don't want all the unregulated subscribers to reply since they could implement a DOS attack.
So, in this case role based security for *writing* to the destination is useful, but only useful for *writing*.
This is why Sergey is allowing this to be specified on the connection factory.
So, I think what we should do is the following:
1) If no security override is specified on the connection factory then the temp destination has full access to everyone. The check in the code will prevent consumers being created by anyone other than the creating connection anyway.
2) If security override is specified on the connection factory then that will take effect, this is useful for the use case explained above. -
20. Re: Permissions on temporary destinations (JBMESSAGING-994)
And
1) Is a higher priority and should be implemented now
2) Is a lower prioriry task and can wait until remoting 2.0
Sergey - can you execute? -
21. Re: Permissions on temporary destinations (JBMESSAGING-994)
Agreed. Usable default with available options for tightening.
-
22. Re: Permissions on temporary destinations (JBMESSAGING-994)
"timfox" wrote:
And
1) Is a higher priority and should be implemented now
2) Is a lower prioriry task and can wait until remoting 2.0
Sergey - can you execute?
Ok, I'll implement option 1 (skipping security checks altogether on temp destinations) and add a JIRA issue for option 2. -
23. Re: Permissions on temporary destinations (JBMESSAGING-994)
Done. Added http://jira.jboss.com/jira/browse/JBMESSAGING-998.
By the way, another way these permissions could be configured may be configuring them per user. Then the configured permissions would apply to all temporary destinations created by the user. It would mean creating or logging in as a separate user if you need to restrict access to your temp destinations, but at least it wouldn't be all-or-nothing. -
24. Re: Permissions on temporary destinations (JBMESSAGING-994)
can wait until remoting 2.0
I'm pleased to announce the availability of Remoting 2.0. :-) -