[
https://issues.apache.org/jira/browse/AMQ-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241257#comment-13241257
]
David Valeri commented on AMQ-3791:
-----------------------------------
I am working on a patch to this issue that would be backwards compatible with
the existing CachedLDAPAuthorizationMap in the trunk; however, I am wondering
if the two LDAP based AuthZ implementations should be merged into one more
flexible implementation that uses the best of both.
> Flexibility, concurrency, security, and compatibility issues in
> CachedLDAPAuthorizationMap
> ------------------------------------------------------------------------------------------
>
> Key: AMQ-3791
> URL: https://issues.apache.org/jira/browse/AMQ-3791
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Documentation
> Reporter: David Valeri
>
> CachedLDAPAuthorizationMap provides support for dynamic AuthZ policy updates
> without restarting the broker; however, I think there are several issues with
> the implementation.
> 1) The underlying structures for storing and managing AuthZ policy are not
> concurrent or synchronized.
> 2) DN manipulation using Strings is error prone and the current
> implementation is case sensitive. This case sensitivity leads to issues with
> AD.
> 3) For synchronous updates to the AuthZ policy, the temp destination policy
> is not reset and may retain out-of-date policy entries.
> 1) Requires examining the usage of these structures and applying the
> necessary protections.
> 2) Can be resolved with better String parsing or through applying the changes
> in AMQ-3770 to CachedLDAPAuthorizationMap as well.
> 3) Can be resolved by clearing the policy entry before repopulating the
> policy from LDAP.
> There are also several enhancements to the configurability of the
> implementation that I see:
> 1) Support user or group membership in the LDAP entry representing a
> permission on a destination. Allowing user DNs or group DNs here makes it
> easier to deal with one-off policies for individual users.
> 2) Group membership in the LDAP entry representing a permission on a
> destination should support use of the full DN, not just the value of the
> member CN.
> 3) The based DN should be fully customizable and the LDAP entry representing
> a permission on a destination should support use of an optional prefix for
> uniqueness. "cn=<PREFIX>read,ou=$,..."
> 4) The name of the GroupPrincipal or UserPrincipal that is created from the
> policy in LDAP should be flexible. For instance, allow the group name or
> user name attribute to be configured.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
