[rabbitmq-discuss] Fwd: Access control documentation

[Edwin Fine]

Ben,

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.

I copied this from
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm

and OAM is described at

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12780_.htm
----------------------
How access control is implemented by WebSphere MQ

 WebSphere(R) 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 *Object Authority Manager (OAM)*. This is
automatically installed and enabled for each queue manager you create,
unless you specify otherwise (as described in Preventing security access
checks<http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13260_.htm>).
The OAM can be replaced by any user or vendor written component that
conforms to the Authorization Service Interface.

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. Using the OAM to control
access to objects<http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13160_.htm>describes
how to grant and revoke this authority.

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(R), to users in the Administrators
group, and users logged in with the SYSTEM ID. User access to the queue
cannot be changed.

WebSphere MQ supplies commands to create, and maintain access control lists.
For more information on these commands, see Using the OAM to control access
to objects<http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqzag.doc/fa13160_.htm>
.

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.

----------------------

Regards,

Ed


On Mon, Sep 29, 2008 at 1:24 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> Anthony,
>
> On Mon, Sep 29, 2008 at 8:26 AM, Anthony <anthony-rabbitmq at hogan.id.au>
> wrote:
>
> > After Ben suggested that some discussion was perhaps warranted on this
> > task, I went away and spoke to my colleagues about our experiences and
> > such. I wrote up the following and ran it past them.. Yes, I approach
> > this very much from the perspective of someone who doesn't code
> > regularly, but is often the one installing/configuring/maintaining
> > stuff based upon supplied requirements. This isn't intended to belt
> > anyone over the head or kick up a stink, but to demonstrate there are
> > some real world needs for finer grained ACLs. Hopefully this inspires
> some
> > thought/commentary on what an ACL system might include.
>
> I think there is a lot of merit in the use cases you have described in
> this mail.
>
> Please understand that realms were not discarded because people didn't
> want fine grained ACLs per se, just that they not particularly well
> specified and hence very difficult to implement properly.
>
> Certainly we would *like* to have some more fine grained AC that what
> we currenly have. Something capability based would probably be nicer
> than plain jane ACLs, but this would be subject to requirements and
> design. In plain English, this could potentially go into the roadmap
> at some stage.
>
> If you would like to improve the chances of doing this, you could
> start a community based initiative which would entail documenting use
> cases and identifying potential solutions, eventually cutting some
> code.
>
> Otherwise you're going to have to be very persuasive to get this
> bumped up the list of priorities :-)
>
> Does anybody else have any views on access control?
>
> HTH,
>
> Ben
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080929/e5b93111/attachment.htm