[
https://issues.apache.org/jira/browse/AMQ-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255088#comment-13255088
]
David Valeri edited comment on AMQ-3791 at 4/16/12 9:41 PM:
------------------------------------------------------------
I attached the first iteration of a patch for the identified issues.
What you get:
1) Added additional defensive measures for synchronous read/write to the
underlying data structures backing the authorization map without altering the
behavior of the underlying data structures (for example, don't alter an
existing structure that returns a live copy of a list)
2) Custom base DNs and search filters for the different permission and
destination types (the limited flexibility in the original implementation made
integrating with AD or other LDAP servers without similar schemas difficult)
3) Compatibility with AD (no string parsing of DNs)
4) Support for directly including a user in a permission instead of requiring a
group (reduces number of groups that need to be created to support fine grained
policies)
5) Ability to choose the attribute that identifies a group or individual member
of a permission so the map is flexible enough to work with non-default
configurations of the LDAP LoginModule.
6) Policy for temp destinations works correctly when using synchronous update
mode
7) Added some tests for working with OpenLDAP and also updated the OpenLDAP
example LDIFs to work with an out-of-the-box OpenLDAP instance. These tests
are @Ignore at the moment since they require an external LDAP server; however
they make gooe examples and are useful for ensuring compatibility in the future.
8) Compatibility with what I am calling "legacy group mapping" where the
permission group members are simply a CN and not a full DN.
9) Supports sub-tree renames at the destination pattern level if the LDAP
server supports them.
What you lose:
1) Push updates against ApacheDS 1.x. At the moment Apache DS 1.x push updates
don't support filters or scope properly. As such, the push update solution
that avoids parsing DNs doesn't work against Apache DS 1.x. I can revert to
using DN parsing for supporting ApacheDS 1.x; however, I will parse them using
LdapName and not raw String manipulation.
Feedback welcome.
was (Author: davaleri):
I attached the first iteration of a patch for the identified issues.
What you get:
1) Added additional defensive measures for synchronous read/write to the
underlying data structures backing the authorization map without altering the
behavior of the underlying data structures (for example, don't alter an
existing structure that returns a live copy of a list)
2) Custom base DNs and search filters for the different permission and
destination types (the limited flexibility in the original implementation made
integrating with AD or other LDAP servers without similar schemas difficult)
3) Compatibility with AD (no string parsing of DNs)
4) Support for directly including a user in a permission instead of requiring a
group (reduces number of groups that need to be created to support fine grained
policies)
5) Ability to choose the attribute that identifies a group or individual member
of a permission so the map is flexible enough to work with non-default
configurations of the LDAP LoginModule.
6) Policy for temp destinations works correctly when using synchronous update
mode
7) Added some tests for working with OpenLDAP and also updated the OpenLDAP
example LDIFs to work with an out-of-the-box OpenLDAP instance. These tests
are @Ignore at the moment since they require an external LDAP server; however
they make gooe examples and are useful for ensuring compatibility in the future.
8) Compatibility with what I am calling "legacy group mapping" where the
permission group members are simply a CN and not a full DN.
What you lose:
1) Push updates against ApacheDS 1.x. At the moment Apache DS 1.x push updates
don't support filters or scope properly. As such, the push update solution
that avoids parsing DNs doesn't work against Apache DS 1.x. I can revert to
using DN parsing for supporting ApacheDS 1.x; however, I will parse them using
LdapName and not raw String manipulation.
Feedback welcome.
> 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
> Attachments: AMQ-3791.patch
>
>
> 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
