<div dir="ltr">Ben,<br><br>I wondered how WMQ does it, and the answer is interesting. I'm not saying WMQ is the be-all and end-all of everything, only that it's a widely used and mature commercial product and it can't hurt to at least look at how it does it.<br>
<br>I copied this from <a href="http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm">http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm</a><br>
<br>and OAM is described at<br><br><a href="http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm">http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm</a><br>
----------------------<br><h1 class="topictitle1">How access control is implemented by WebSphere MQ <br></h1>
<div><p> </p>
<p>WebSphere<sup>®</sup> MQ
uses the security services provided by the underlying operating system. An
access control interface called the Authorization Service Interface is part
of WebSphere MQ. WebSphere MQ
supplies an implementation of an access control manager (conforming to the
Authorization Service Interface) known as the <em>Object Authority Manager
(OAM)</em>. This is automatically installed and enabled for each queue manager
you create, unless you specify otherwise (as described in <a href="http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13260_.htm" title="">Preventing security access checks</a>).
The OAM can be replaced by any user or vendor written component that conforms
to the Authorization Service Interface.</p>
<p>The OAM exploits the security features of the underlying operating system,
using operating system user and group IDs. Users can access WebSphere MQ
objects only if they have the correct authority. <a href="http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13160_.htm" title="">Using the OAM to control access to objects</a> describes
how to grant and revoke this authority.</p>
<p>The OAM maintains an access control list (ACL) for each resource that it
controls. Authorization data is stored on a local queue called SYSTEM.AUTH.DATA.QUEUE.
Access to this queue is restricted to users in the mqm group, and additionally
on Windows<sup>®</sup>,
to users in the Administrators group, and users logged in with the SYSTEM
ID. User access to the queue cannot be changed.</p>
<p>WebSphere MQ
supplies commands to create, and maintain access control lists. For more information
on these commands, see <a href="http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13160_.htm" title="">Using the OAM to control access to objects</a>.</p>
<p> WebSphere MQ
passes the OAM a request containing a principal, a resource name, and an access
type. The OAM grants or rejects access based on the ACL that it maintains. WebSphere MQ
follows the decision of the OAM; if the OAM cannot make a decision, WebSphere MQ
does not allow access.</p><p>----------------------</p><p>Regards,</p><p>Ed<br></p>
</div><br><br><div class="gmail_quote">On Mon, Sep 29, 2008 at 1:24 PM, Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Anthony,<br>
<div class="Ih2E3d"><br>
On Mon, Sep 29, 2008 at 8:26 AM, Anthony <<a href="mailto:anthony-rabbitmq@hogan.id.au">anthony-rabbitmq@hogan.id.au</a>> wrote:<br>
<br>
> After Ben suggested that some discussion was perhaps warranted on this<br>
> task, I went away and spoke to my colleagues about our experiences and<br>
> such. I wrote up the following and ran it past them.. Yes, I approach<br>
> this very much from the perspective of someone who doesn't code<br>
> regularly, but is often the one installing/configuring/maintaining<br>
> stuff based upon supplied requirements. This isn't intended to belt<br>
> anyone over the head or kick up a stink, but to demonstrate there are<br>
> some real world needs for finer grained ACLs. Hopefully this inspires some<br>
> thought/commentary on what an ACL system might include.<br>
<br>
</div>I think there is a lot of merit in the use cases you have described in<br>
this mail.<br>
<br>
Please understand that realms were not discarded because people didn't<br>
want fine grained ACLs per se, just that they not particularly well<br>
specified and hence very difficult to implement properly.<br>
<br>
Certainly we would *like* to have some more fine grained AC that what<br>
we currenly have. Something capability based would probably be nicer<br>
than plain jane ACLs, but this would be subject to requirements and<br>
design. In plain English, this could potentially go into the roadmap<br>
at some stage.<br>
<br>
If you would like to improve the chances of doing this, you could<br>
start a community based initiative which would entail documenting use<br>
cases and identifying potential solutions, eventually cutting some<br>
code.<br>
<br>
Otherwise you're going to have to be very persuasive to get this<br>
bumped up the list of priorities :-)<br>
<br>
Does anybody else have any views on access control?<br>
<br>
HTH,<br>
<font color="#888888"><br>
Ben<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>
</div></div></blockquote></div><br></div>