[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] [Commented] (AMQ-3791) Flexibility, concurrency, security, and compatibility issues in Cached
From:       "Dejan Bosanac (Commented) (JIRA)" <jira () apache ! org>
Date:       2012-03-29 15:44:25
Message-ID: 1311424737.33095.1333035865751.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/AMQ-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241321#comment-13241321 \
] 

Dejan Bosanac commented on AMQ-3791:
------------------------------------

We just need to make sure that's documented well for people using current plugins and \
want to upgrade.  
> 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

        


[prev in list] [next in list] [prev in thread] [next in thread]