activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Gallo (JIRA)" <>
Subject [jira] Updated: (AMQ-908) Authorization plugin should have configurable principal classes
Date Tue, 12 Dec 2006 07:24:02 GMT
     [ ]

Ken Gallo updated AMQ-908:

    Attachment: authorizationPlugin.patch


<authorizationEntry queue="USERS.>" read="users" write="users" admin="users" groupClass=""

I've noticed that xbean sets "admin" before "groupClass" in the xml config of authorizationEntry
(I think its alphabetical), so even if you set the principal class, admin is intialized with
the default org.apache.activemq.jaas.GroupPrincipal class. 

I've renamed "groupClass" to "ACLPrincipal" so the principal class to be used can be set first
before xbean sets admin.

So it should be:

<authorizationEntry queue="USERS.>" read="users" write="users" admin="users" ACLPrincipal=""

> Authorization plugin should have configurable principal classes
> ---------------------------------------------------------------
>                 Key: AMQ-908
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 4.0.1
>            Reporter: Aaron Mulder
>             Fix For: 4.2.0
>         Attachments: authorizationPlugin.patch, authorizationPlugin.patch, AuthorizationPlugin.patch,
> Currently, if you configure the authorization plugin, it assumes that all principals
listed should be of type {{org.apache.activemq.jaas.GroupPrincipal}}.  This is OK if you're
using ActiveMQ LoginModules, but since there's a fairly small supply of those, it would be
great if you could use arbitrary login modules and tell the authorization plugin which principal
classes to use.  For example, {{groupClass="}} or
something like that.  A good first step would be to let you change the group class.  A good
second step would be to let you specify user and group classes and then somehow indicate which
names are which (e.g. {{admin="administrators,user:aaron,user:bob"}} or whatever).  Someday
maybe it will be nice to support any arbitrary combination of principal classes but that seems
far away.
> When instantiating the principal classes, I imagine we should use a constructor with
a single String argument if available, or else a default constructor plus a "setName" method,
or else I guess bail.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message