activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Resolved] (AMQ-4685) LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
Date Sat, 02 Nov 2013 13:51:18 GMT


Claus Ibsen resolved AMQ-4685.

    Resolution: Fixed

Thanks for the detailed explanation and the patch.

> LDAPLoginModule throws InvalidNameException when resolving LDAP aliases
> -----------------------------------------------------------------------
>                 Key: AMQ-4685
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.x
>         Environment: OS Independent
> OpenLDAP 2.4
>            Reporter: Igor Podolskiy
>            Assignee: Claus Ibsen
>            Priority: Minor
>             Fix For: 5.10.0
>         Attachments: handle-ldap-aliases-v1.patch
> Some LDAP servers allow you to define aliases for objects. For example, consider the
following LDAP directory layout:
> {code}
> dc=example,dc=com
>    ou=ActiveMQ
>       ou=Users
>       ou=Roles
>       ou=Destinations
>    ou=People
> {code}
> In this layout, accounts specific to ActiveMQ go under ou=Users,ou=ActiveMQ. However,
some accounts in ou=People should also be able to have access to the ActiveMQ server. To avoid
duplicating accounts, you can have the regular account (objectClass=inetOrgPerson) in ou=People
and create an LDAP alias (objectClass=alias) for it in ou=People. The LDAP server then takes
care about the alias resolution.
> The JNDI LDAP client supports LDAP alias dereferencing as well. However, the search results
for resolved aliases are different. For regular entries, SearchResult.getName() returns a
relative DN and SearchResult.isRelative() returns true; for dereferenced aliases, SearchResult.getName()
returns a full LDAP URI with the DN of the alias target (for example, 'ldap://localhost:389/uid=bob,ou=People,dc=example,dc=com')
and SearchResult.isRelative() returns false (as documented, for example, in [1]).
> The code in o.a.a.jaas.LDAPLoginModule does not make this distinction. It assumes that
all returned names are RDNs and passes them to NameParser.parse() which in turn raises a NamingException
because an LDAP URI is obviously not an LDAP (R)DN.
> The attached patch resolved the problem at least for my configuration. If isRelative()
returns false, the name is parsed as an URI. Per definition of LDAP URIs, the path component
is the distinguished name, which is then taken.
> Of course, this does not take care of multiple layers of aliases, aliases for containers
and so on - I just found it over the course of setting up LDAP  authentication in my system,
which happens only to alias user accounts. It works for me with the patch and seems not to
make things worse :) If needed, maybe I can do some further tests and/or correct the patch.
> [1]

This message was sent by Atlassian JIRA

View raw message