I'm really mystified by why you want to rely on remote ldap to look up
a connection factory or destinations. I don't think you've thought
through what information needs to be distributed where by what means
and I think you are going towards a much harder to administer
heavyweight solution than you need.
For connection factories:
ldap: you need to tell each client where the ldap server is.
amq properties file: you need to tell each client the broker url to use
This is the same amount of information... but with the properties file
you don't need an ldap server.
Furthermore, IMO the ldap solution won't really work except for
clients that are small enough to not need connection pooling. Even
for implementations that might be able to export a connection pooling
connection factory from remote ldap, I can't imagine that you'd want
the pooling configuration anywhere but in the application that needs
the pooling.
For destinations with security:
You need broker side authorization anyway, since any client can just
create a connection factory and destinations without ldap anyway. So
what good does it do to set up the destinations in ldap?
I'm not trying to tell you what you should or shouldn't do, but I'd
like to understand how ldap actually meets your needs... and not
getting it.
thanks
david jencks
On Mar 18, 2009, at 9:56 AM, janylj wrote:
Hello Huntc,
I read your blog especially the Authorisation part. I think we are
talking
about the same thing. The LDAP server I set up also uses ACI to
grant or
limit the access to specific topic/queue.
I guess this discussion is mainly about whether ActiveMQ has an
embedded
JNDI provider for centralized management. Because the LDAP server I
have to
set up is exclusive for ActiveMQ, however, the availability of LDAP
server
is separate from ActiveMQ. In other words, if LDAP says you could
use this
queue, you still could not use the queue if ActiveMQ broker is down.
Vice
versa, if LDAP server is down, although all the resources are
available in
the JMS broker, you still could not uses any of them.
Lijun
huntc wrote:
janylj wrote:
I was trying to have a centralized repository of destinations and
ConnectionFactory. I could use a uniform namespace for destination
to
avoid conflicting. However, I don't want to allow users creating
destination or ConnectionFactory on the fly. I would like them
accessing
the broker only through administrative objects.
I believe you are going about this the wrong way. What you really
want is
topic/queue authorisation i.e. only let certain authenticated users
do
certain things within the broker.
You might find my blog entry on securing ActiveMQ useful.
Authorisation is
covered.
http://christopherhunt-software.blogspot.com/2009/03/mutual-ssl-authentication-and-ldap.html
--
View this message in context:
http://www.nabble.com/ActiveMQ-JNDI-support-only-for-testing--tp21925743p22583570.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
