[ https://issues.apache.org/activemq/browse/AMQ-908?page=all ]
Ken Gallo updated AMQ-908:
--------------------------
Attachment: AuthorizationPlugin.patch
Implemented like so:
<authorizationPlugin>
<map>
<authorizationMap>
<authorizationEntries>
<authorizationEntry queue=">" read="admins" write="admins"
admin="admins" groupClass="org.apache.activemq.jaas.GroupPrincipal" />
<authorizationEntry queue="USERS.>" read="users" write="users"
admin="users"
groupClass="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
/>
</authorizationEntries>
</authorizationMap>
</map>
</authorizationPlugin>
Creates an instance of the groupClass through the constructor with String name
as a parameter.
If the groupClass doesn't have a constructor then it uses the setName() method.
If both fail, an exception is thrown.
> Authorization plugin should have configurable principal classes
> ---------------------------------------------------------------
>
> Key: AMQ-908
> URL: https://issues.apache.org/activemq/browse/AMQ-908
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 4.0.1
> Reporter: Aaron Mulder
> Fix For: 4.2.0, 4.0.3
>
> Attachments: 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="weblogic.security.principal.WLSGroupImpl}} 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:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
