LDAP Security Plugin For ActiveMQ. User Guide

Transcription

1 LDAP Security Plugin For ActiveMQ User Guide Joe Fernandez Total Transaction Management, LLC An Open Source Solutions Company 570 Rancheros Drive, Suite 140 San Marcos, CA

2

3 i Table of Contents 1 INTRODUCTION INSTALLATION AND CONFIGURATION Installation ActiveMQ Configuration File Security Plugin Bean Definition Security File LdapConnectorBean AuthenticatorBean AuthorizationMapBean Logging AUTHENTICATION AUTHORIZATION Controlling Access to Temporary Resources (Destinations) Wildcards CAMEL AUTHENTICATION AND AUTHORIZATION BETWEEN MESSAGE BROKERS JMX MBEAN ABBREVIATIONS AND ACRONYMS...24

4 2 1 Introduction TTM s LDAP Security Plugin (SP) is an ActiveMQ plugin module that uses a LDAP directory server (DS) to provide dynamically reconfigurable authentication and authorization (A&A) security services. The primary benefit of using a LDAP DS is that all A&A information, which pertains to ActiveMQ clients and resources (i.e., topics and queues), is centrally and securely stored and managed. This is especially attractive for large enterprise class environments that employ 10 s if not 100 s of ActiveMQ message brokers. The combination of SP and DS also provides for dynamic runtime configuration. This feature allows you to make modifications to the A&A information in the DS and not have to stop and restart the ActiveMQ message broker(s) to have those modifications take effect. ActiveMQ is both a message oriented middleware (MOM) system and an extensible messaging framework. One method of extending ActiveMQ s functionality is through its plugin architecture, which allows you to extend the core messaging engine s functionality. This plugin architecture is similar, in concept, to the plugin architecture found in the Apache web server. That is, you develop a plugin module that adheres to a defined interface, which then allows the plugin to be included in the core engine s main event processing chain. The SP adheres ActiveMQ s plugin interface, and by doing so is able to intercepts those client-related events (i.e., connect, read/receive, write/send, admin/create/remove) that require authentication and/or authorization. For example, when a messaging client establishes a connection with the broker, the SP intercepts the connection request event and uses the connection s username and password properties to authenticate the client against the DS. The SP will also authorize clients to ensure they have been issued the proper access rights for the corresponding broker s resources (i.e., queues and topics). The SP connects or binds to a central LDAP directory service to: 1. Authenticate clients 2. Retrieve clients security credentials 3. Retrieve the access control lists (ACLs) assigned to a broker s resources (destinations). This package has been certified for the officially released version of ActiveMQ 5.1. It has not been certified with prior releases or SNAPSHOT versions of 5.1. The package also includes an administrative JMX MBean. Through this JMX MBean, you can view the SP s properties and issue commands to the SP.

5 2 Installation and Configuration Installation It is very easy to install the SP. Extract the file called, ttm-ldapsecurity-<version>.jar from the ttmldapsec.zip file and place the jar file in the ACTIVEMQ_HOME/lib/optional directory. That s it! You ve installed the SP. Now we need to configure the ActiveMQ message broker to load the SP, which is explained in the next section. 2.2 ActiveMQ Configuration File To have the ActiveMQ message broker load the SP on startup, you must define a SP bean within the message broker s Spring XML configuration file (ACTIVEMQ_HOME/conf/activemq.xml). There are two options you can take with the first being depicted in the XML listing below, which is a snippet of a message broker s XML configuration file. Note how the SP bean, with an id of securityplugin, is defined outside the <broker> element and is referenced via the <broker> element s plugins attribute. <!-- ActiveMQ Broker Configuration File --> <beans xmlns=" xmlns:amq=" xmlns:xsi=" xsi:schemalocation=" <!-- Allows us to use system properties as variables in this configuration file --> <bean class="org.springframework.beans.factory.config.propertyplaceholderconfigurer" /> <broker xmlns=" brokername="secprototype" datadirectory="${activemq.base}/data" plugins="#securityplugin"> <transportconnectors> <transportconnector name="openwire" uri="tcp://localhost:61616" /> </transportconnectors> </broker> <bean id="securityplugin" class="com.atomicmq.security.ldap.ldapsecurityplugin"/> </beans>

6 That s it! With those two minor additions to the message broker s XML configuration file, you ve configured the message broker to load the SP and enabled LDAP-based security for the broker. Subsequent sections of this document will show you how to configure the SP to have it successfully connect to and properly search the DS. The second option is depicted in the XML snippet below. With this approach, note how the SP bean is defined within the <broker> element s <plugins> sub-element and that it is no longer referenced via the broker element s plugins attribute. Also note how you must specify a name space for the SP bean (i.e., xmlns= ). 4 <!-- ActiveMQ Broker Configuration File --> <beans xmlns=" xmlns:amq=" xmlns:xsi=" xsi:schemalocation=" <!-- Allows us to use system properties as variables in this configuration file --> <bean class="org.springframework.beans.factory.config.propertyplaceholderconfigurer" /> <broker xmlns=" brokername="secprototype" datadirectory="${activemq.base}/data""> <transportconnectors> <transportconnector name="openwire" uri="tcp://localhost:61616" /> </transportconnectors> <plugins> <bean id="securityplugin" class="com.atomicmq.security.ldap.ldapsecurityplugin " xmlns=" </plugins> </broker> </beans> If you are currently using a security plugin and wish to use TTM s SP, then you must first remove the security plugins currently in use.

7 5 After you ve installed the SP and configured the broker to load it, you ll note the following INFO statements being put out during the broker s startup phase. INFO LdapSecurityPlugin INFO LdapSecurityPlugin - Connecting to directory server - Started If the SP can connect to the DS, you should not see any amount of time in between the output of the two above statements to the console. However, if the DS is not available, the SP will wait for the DS. The amount of time it waits is governed by the LdapConnectorBean's connectiontimeout property, which by default is set to 5000 milliseconds or 5 seconds. If the timeout expires and the SP could not connect, you will see the following exception statements being output in between the two above statements. ERROR LdapConnectorBean - createcontext - initial bind to directory failed, got this exception ERROR LdapConnectorBean - javax.naming.communicationexception: :10389 [Root exception is java.net.sockettimeoutexception: connect timed out] During its lifetime, the SP attempts to connect to the DS during these events: 1. During its startup as described above 2. Whenever a client connects to the broker 3. When it is time to refresh its access control lists. More on this in the next section. 2.3 Security Plugin Bean Definition The configuration examples in the previous section do not describe the SP bean s properties; there is a handful so let s take a close look at them. The example SP bean definition and subsequent table below lists all the properties, their default values, and a brief description. <bean id="securityplugin" class=" com.atomicmq.security.ldap.ldapsecurityplugin "> <property name="securityfile" value="ldapsecurity.xml"/> <property name="authenticatorbeanname" value="authenticator"/> <property name="authorizationbeanname" value="aclmap"/> <property name="plugindisabled" value="false"/> <property name="aclrefreshinterval " value="60"/> </bean>

8 6 Property Name Default Value Description securityfile ldapsecurity.xml This property specifies the name and location of the Spring XML file that defines the Spring container or BeanFactory (we ll refer to this as the security BeanFactory ) that dispenses the SP s main authentication and authorization beans. The beans dispensed by the security BeanFactory are fully described in subsequent sections of this document. For this property s value, you can specify an absolute path (e.g., /tmp/ldapsecurity.xml), URL (e.g., or simply a file name. If it is just a file name, as per the default value, then the file must be located in the ActiveMQ broker s class path (i.e., ACTIVEMQ_HOME/conf). authenticatorbeanname authenticator Specifies the bean id assigned to the authenticator bean that is dispnsed by the security BeanFactory. The authentication bean is used for searching or querying the DS for a client s user name, password, and groups/roles and also to authenticate the client. authorizationbeanname aclmap Specifies the bean id assigned to the authorization bean that is dispnsed by the security BeanFactory. The authorization bean is used for searching or querying the DS for destination access control lists (ACLs) and authorizing a client. plugindisabled false Used for disabling the plugin on startup. Setting it to true disables the plugin and the A&A services that it provides. During runtime, you can later enable/disable the plugin via its JMX MBean. aclrefreshinterval 60 This property specifies the frequency at which the SP will connect to the DS in order to refresh its inmemory ACLs. During startup, the SP will connect to the DS to initialize its ACLs. Then during runtime, it will connect to the DS to refresh the ACLs at the frequency specified by this property. The default is once every 60 seconds. You may want to override the default value according to how often access control information will change for your particular environment. Through the SP s JMX MBean, you can also force an immediate refresh of the ACLs or modify the property s value. Please not that the new value entered through the MBean will not be persisted out to the broker s XML file.

9 If you do not require any modifications to the SP bean s default property values, you simply add one of the following statements, as described in the previous section, to the broker s XML configuration file. <bean id="securityplugin" class="com.atomicmq.security.ldap.ldapsecurityplugin"/> 7 <bean id="securityplugin" class="com.atomicmq.security.ldap.ldapsecurityplugin " xmlns=" 2.4 Security File This section describes the Spring XML file that defines the previously mentioned security BeanFactory. Also as previously described, the name and location of this file is specified through the SP bean s securityfile property. If you use the property s default value of ldapsecurity.xml, then you must locate the file in the message broker s ACTIVEMQ_HOME/conf directory. You are not required to stop and restart the broker if you make modifications to the file. The SP will automatically detect that the file has been modified and reloads it. The file defines three beans: LdapConnectorBean, AuthenticatorBean, and AuthorizationMapBean LdapConnectorBean The LdapConnectorBean is wired to the AuthenticatorBean and AuthorizationMapBean; it is used by these two beans to connect to the LDAP server. The table below lists and describes the LdapConnectorBean s properties. Property Name connectionurl Default Value Description Specifies the URL that is used to connect to the directory server. The value is assigned to the PROVIDER_URL context environment property. For example ldap:// :10389 connectionusername connectionpassword There is no default value for this propert; you must assign it a value. The user name and password that the beans use when searching the DS for clients security credentials and ACLs.

10 8 connectionprotocol authentication simple connectiontimeout 5000 The values are assigned to the SECURITY_PRINCIPAL and SECURITY_CREDENTIALS context environment properties. This is the protocol that is used to connect to the directory server. You may need to modify the default for your environment. The value is assigned to the CONNECTION_PROTOCOL context environment property. The value is assigned to the SECURITY_AUTHENTICATION context environment property. This is the amount of time (milliseconds) that the bean will wait when attempting to connect to the directory server. This is an example LdapConnectorBean definition, which relies on default values for some of the properties. <bean id="connectorbean" class="com.atomicmq.security.ldap.ldapconnectorbean"> <property name="connectionurl" value="ldap:// :10389"/> <property name="connectionusername" value="uid=admin,ou=system"/> <property name="connectionpassword" value="secret"/> </bean> AuthenticatorBean The AuthenticatorBean is used for authenticating ActiveMQ clients and retrieving portions of the the clients security context (username, roles, etc.). This bean is automatically wired to the LdapConnectorBean. The table below lists and describes the AuthenticatorBean s properties. Property Name Default Value Description userbase This property specifies the distinguished name (DN) that serves as the base or root of the directory information tree (DIT) that contains the user or client entries. You must specify a value for this property. For example, usersearchfilter "(uid={0})" <property name="userbase" value="ou=users,ou=system"/> Specifies the search filter that is used for searching user entries underneath the base defined by the 'userbase' property. The '{0}' substring is replaced with the user name as passed in via the client's connection. You may have to modify the default for your particular environment.

11 userrolename usersearchsubtree rolebase "ou" true LDAP Security Plugin for ActiveMQ Specifies the attribute name, w/in a user entry, that specifies the role(s) or group(s) that the user has been assigned to. The given value is just an example; you will have to modify it for your particular environment. The following example user entry defines a user with a uid of 'joef' that has been assigned the role of 'admin', role1, and 'user'. dn: uid=joef,ou=users,ou=system objectclass: organizationalperson objectclass: person objectclass: inetorgperson cn: Joe Smith employeetype: slacker ou: admin ou: user ou: role1 sn: Smith uid: joef userpassword:: cgfzc3dvcmq= Also see the 'rolebase' property below. Set to true (default) if you'd like to search the entire user subtree defined by the "userbase" property. If set to 'false', only a one level search will be performed. This is an optional property that is used to specify the DN used for searching role/group entries. It essentially specifies the base or root of a DIT that contains role/group entries. A role entry, within this DIT, specifies a list of users that are assigned to a particular role or group. Here are the possible combinations of how a particular user's roles are specified via a combination of user and/or role entry: 1. All of a user's roles are specified by the role entries found in this (rolebase) DIT. In other words, a user entry, residing in the userbase DIT, does not have an attribute that specifies the user's roles; therefore, all of the user's roles are specified by role entries in this rolebase DIT. 9

12 2. This rolebase DIT is not used and all roles are specified via the user entries The roles are specified via a combination of user and role entries found in the userbase and rolebase DITs, respectively. This DIT is referenced only after a user has been authenticated. Here s an example DN for this DIT <property name="rolebase" value="ou=groups,ou=system"/> rolesearchfilter "(member={0})" Specifies the filter that is used for searching users role entries underneath the (rolebase) DIT. The default value for the filter is asking for those role entries in this DIT that have a 'member' attribute whose value contains the user's DN, where {0} is replaced with the DN. You also have available the {1} parameter, which is assigned the username (uid). rolename "cn" Specifies the attribute name, w/in a role entry, whose value specifies the name of the role or group assigned to the entry. For example, the cn attribute in this role entry is used to specify the 'user' role for the corresponding entry. dn: cn=user,ou=groups,ou=system objectclass: groupofuniquenames objectclass: extensibleobject cn: user member: uid=joef,ou=users,ou=system member: uid=linda,ou=users,ou=system member: uid=marisa,ou=users,ou=system member: uid=shadow,ou=users,ou=system member: uid=diego,ou=users,ou=system uniquemember: =admin, =system Example:

13 11 rolesearchsubtree true timelimit 0 dereflinkflag false <property name="rolename" value="cn"/> Set to true (default) if you'd like to search the entire optional 'rolebase' subtree. If set to 'false', only a one level search will be performed. The time limit (milliseconds) imposed on the searches conducted via this bean. The default value is 0, which means to wait indefinitely. Specifies whether links will be de-referenced during the search. Below is an example AuthenticatorBean definition, which relies on default values. Note the use of the 'autowire' attribute. This is used to automatically wire this bean with the LdapConnectorBean. To change this to an explicit reference, remove the 'autowire' attribute and use the following property. <property name="ldapconnectorbean" ref="connectorbean"/> Or you can use the following constructor reference. <constructor-arg ref="connectorbean"/> Using an explicit reference allows you to define more than one LdapConnectorBean and have this and the AuthorizationMapBean reference different LDAP servers (if required). The id's value of "authenticator" is the default id value used by the LDAP plugin module. If you modify the id's value, make sure you also modify the plugin module's bean element within the ActiveMQ broker's XML configuration file. <bean class="com.atomicmq.security.ldap.authenticatorbean" id="authenticator" autowire="autodetect"> <property name="userbase" value="ou=users,ou=system"/> <property name="rolebase" value="ou=groups,ou=system"/> </bean> AuthorizationMapBean This bean is used for conducting authorization-related searches on the LDAP server. The information provided via this bean is used to search the directory for access control policies that define access rights to ActiveMQ destinations (i.e., queues and topics). These policies are expressed as access control lists (ACLs).

14 An ACL entry specifies a particular access right (privilege) that is granted to one or more roles (groups) for a particular destination. The three possible access rights are: 'read', 'write', and 'admin'. The 'admin' right/privilege is required for creating destinations. 12 Property Name Default Value Description This property specifies the distinguished name (DN) that identifies the base or root of the DIT used for searching 'topic' ACL entries. For example, topicsearchmatchingbase <property name="topicsearchmatchingbase" value="ou=topics,ou=destinations,ou=system"/> NOTE: topics and queues must be kept in separate DITs. queuesearchmatchingbase This property specifies the distinguished name (DN) that serves as the base or root of the DIT used for searching 'queue' ACL entries. For example, <property name=" queuesearchmatchingbase " value="ou=queues,ou=destinations,ou=system"/ > destinationattrname uid Specifies the attribute within a destination's DN that identifies the destination's physical name. In the following example ACL entry, the DN's 'uid' attribute identifies the destination's physical name as 'TEST.Q'. dn:uid=test.q,ou=topics,ou=destinations,o=a mq,dc=example,dc=com You can use wildcards as defined by the ActiveMQ syntax. For example, this DN is used for specifying ALL destinations with a prefix of 'TEST.'. dn:uid=test.>,ou=topics,ou=destinations,o=am qdc=example, dc=com privilegeattrname cn Specifies the name of the attribute, w/in an ACL entry, whose value specifies a privilege (read, write, admin) being granted to all groups or roles

15 specified by the entry. The value assigned to this attribute must be either read, 'write', or 'admin'. Any other value will result in an exception being thrown. This example grants 'read' access to TEST.TOPIC for everyone assigned to the 'users' or 'admin' role/group. dn:cn=read,uid=test.topic,ou=topics,ou=desti nations,o=amq,dc=example,dc=com objectclass: groupofuniquenames objectclass: top cn: read uniquemember: users uniquemember: admin This example grants admin access to all topics whose names start with a prefix of "ActiveMQ.Advisory." for everyone assigned to the 'users' or 'admin' roles. dn:cn=admin,uid=activemq.advisory.\>,ou=topi cs, ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: admin uniquemember: users uniquemember: admin Specifies the name of the attribute, w/in an ACL entry, whose value(s) specifies the groups or roles that have been granted the privileges specified in the ACL entry. 13 roleattrname uniquemember The following example ACL grants 'admin' access rights to the queue called "TEST.Q" for all users that have been assigned the role of 'admin' or 'users'. dn:cn=admin,uid=test.q,ou=queues,ou=destin ations,o=amq,dc=example,dc=com objectclass: groupofuniquenames

16 cn: admin uniquemember: users uniquemember: admin 14 Example: timelimit 0 dereflinkflag false <property name="roleattrname" value="uniquemember"/> The time limit (milliseconds) imposed on the searches conducted via this bean. The default value is 0, which means to wait indefinitely. Specifies whether links will be de-referenced during the search. Below is an example AuthorizationMapBean definition, which relies on default values. Note the use of the 'autowire' attribute. This is used to automatically wire this bean with the LdapConnectorBean. To change this to an explicit reference remove the 'autowire' attribute and use the following property. <property name="ldapconnectorbean" ref="connectorbean"/> Or you can use the following constructor reference. <constructor-arg ref="connectorbean"/> Using an explicit reference allows you to define more than one LdapConnectorBean and have this and the AuthenticatorBean reference different LDAP servers (if required). The id's value of "aclmap" is the default id value used by the LDAP plugin module. If you modify the id's value, make sure you also modify the plugin module's bean element within the ActiveMQ broker's XML configuration file. <bean class="com.atomicmq.security.ldap.authorizationmapbean" id="aclmap" autowire="autodetect"> <property name="topicsearchmatchingbase" value="ou=topics,ou=destinations,o=amq,dc=example,dc=com"/> <property name="queuesearchmatchingbase" value="ou=queues,ou=destinations,o=amq,dc=example,dc=com"/> </bean> The example below illustrates all three beans within a security file.

17 15 <beans> <bean id="connectorbean" class="com.atomicmq.security.ldap.ldapconnectorbean"> <property name="connectionurl" value="ldap:// :10389"/> <property name="connectionusername" value="uid=admin,ou=system"/> <property name="connectionpassword" value="secret"/> </bean> <bean class="com.atomicmq.security.ldap.authenticatorbean" id="authenticator" autowire="autodetect"> <property name="userbase" value="ou=users,ou=system"/> <property name="rolebase" value="ou=groups,ou=system"/> </bean> <bean class="com.atomicmq.security.ldap.authorizationmapbean" id="aclmap" autowire="autodetect"> <property name="topicsearchmatchingbase" value="ou=topics,ou=destinations,o=amq,dc=example,dc=com"/> <property name="queuesearchmatchingbase" value="ou=queues,ou=destinations,o=amq,dc=example,dc=com"/> </bean> </beans> If during runtime the security file is modified, the SP will automatically reload it; there is no need to stop and restart the message broker to have the modifications take effect. 2.5 Logging To turn on the plugin s trace logging, locate the ACTIVEMQ_HOME/conf/ log4j.properties file and change the root logger s debug level from INFO to TRACE as this line illustrates. log4j.rootlogger=trace, stdout, out Please note that the plugin s trace level logging will produce a substantial amount of trace statements to both stdout and the ACTIVEMQ_HOME/data/activemq.log file. 3 Authentication The SP authenticates an ActiveMQ client while the broker is processing the client s connection request. The client s connection request must provide a username and password; if not, the plugin throws an exception and will disallow the connection request. The plugin will first use the DS administrator s username and password, which are provided via the LdapConnectorBean, to bind to the DS. After successfully binding to the DS, it will use the AuthenticatorBean s userbase and usersearchfilter properties to search for an entry in the DS that has an attribute value that matches the connection s username property value. If the search is not successful, the

18 plugin will throw an exception and will disallow the client s connection request. If the search is successful, the plugin will then bind to the DS with the client s credentials (i.e., username and password). If that bind succeeds, the user is authenticated; else the connection request is disallowed. If the client is authenticated, the plugin will then use the AuthenticatorBean s userrolename property to determine if the found entry contains role information for the client. If it does, the roles are assigned to the clients security context. The plugin then uses the AuthenticatorBean s rolebase, rolesearchfilter, and rolename properties to determine if additional roles exist for the client under the DIT that is specified by the rolebase property. 16 The client s security credentials (username, groups) are collectively referred to as a security context. Every time an ActiveMQ client connects to the broker, the SP will bind to the DS to authenticate the client. If the client is authenticated, the SP then creates a security context for the client and binds the context to the client s connection object. Therefore, subsequent operations (e.g., read, write) made through that particular connection will not require the SP to reauthenticate against the directory service. This helps maintain an acceptable level of performance during the connection s lifecycle. The connection s security context is dissolved when the connection is closed. 4 Authorization When a client sends a request to the broker to perform an operation (read, write, admin) on a resource (topic, queue), the plugin intercepts the operation request and ensures that the client has been authenticated and that it has also been granted the proper access rights to perform the operation on the destination. The plugin uses the AuthorizationMapBean to retrieve information from the DS that is used to construct the access control lists (ACLs) for the broker s resources. The read and write access rights are given to a client to read and write to a particular destination. The admin access right is assigned to a client so that it can create and remove a destination. The following is a sample LDAP Data Interchange Format (LDIF) that defines ACLs for several topics. Note that one of the entries uses wildcarding to designate a set of resources all having a particular prefix. In this case, the set of resources are all the advisory topics. See the section on wildcards for more information. # The root of the topic DIT. The DN s value would be assigned to the # AuthorizationMapBean s topicsearchmatchingbase property dn: ou=topics,ou=destinations,o=amq,dc=example,dc=com

19 objectclass: organizationalunit ou: topics LDAP Security Plugin for ActiveMQ 17 # An entry for a topic called topic1. The uid string value would be assigned to the # AuthorizationMapBean s destinationattrname property. dn: uid=topic1,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: uidobject uid: topic1 # This subentry to the topic1 entry, states that the admin privilege be assigned to all # clients that have been assigned to the role or group called role1. The cn string value # would be assigned to the AuthorizationMapBean s privilegeattrname property and # the uniquemember string value would be assigned to the AuthorizationMapBean s # roleattrname property. privilegeattrname dn: cn=admin,uid=topic1,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: admin uniquemember: role1 dn: cn=read,uid=topic1,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: read uniquemember: role2 dn: cn=write,uid=topic1,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: write uniquemember: role3 # By default, support for Advisory topics is enabled for ActiveMQ. Because of this, you # should create an access control list that grants everyone read, write and admin privileges # for all advisory topics. Note the use of the > ActiveMQ wildcard. See the section on # wildcards for more information. dn: uid=activemq.advisory.\>,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: uidobject uid: ActiveMQ.Advisory.>

20 dn: cn=admin,uid=activemq.advisory.\>,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: admin uniquemember: all dn: cn=write,uid=activemq.advisory.\>,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: write uniquemember: all dn: cn=read,uid=activemq.advisory.\>,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: read uniquemember: all Controlling Access to Temporary Resources (Destinations) To enable access control to all temporary destinations you must create a special resource or destination entry within the DIT that is pointed to by either the AuthorizationMapBean s topicsearchmatchingbase or queuesearchmatchingbase property values. In other words, you can place it in either the topics or queues ACL DIT. This single resource entry must be identified as having the name of TemporaryResources ; the name is not case sensitive. For example, this would be the LDIF for the TemporaryResources entry if you were to place it underneath the topicsearchmatchingbase DIT, as defined in the previous section. # The root of the topics ACL DIT dn: ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: organizationalunit ou: topics # An entry for controlling temporary resources. dn: uid= TemporaryResources,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: uidobject uid: TemporaryResources

21 # The following three subentries to the TemporaryResources entry, state that the admin, # read, and write privileges for all temporary resources be assigned only to those # clients that have been assigned to the role or group called temps. dn: cn=admin,uid= TemporaryResources,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: admin uniquemember: temps dn: cn=read,uid= TemporaryResources,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: read uniquemember: temps dn: cn=write,uid= TemporaryResources,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: write uniquemember: temps 19 If you don not define a TemporaryResources entry, everyone will have read, write, and admin privileges for all temporary resources. 4.2 Wildcards The SP suppports the following destination name wildcards, which are an ActiveMQ-specific convenience mechanism used to refer to multiple destinations within a destination name hierarchy. The. character is used to separate names in a path. The * character is used to match any name in a path The > character is used to recursively match any destination starting from this name The table below illustrates some examples of wildcard usage. Subscription PRICE.> PRICE.STOCK.> Meaning Any price for any product on any exchange Any price for a stock on any exchange

22 PRICE.STOCK.NASDAQ.* Any stock price on NASDAQ PRICE.STOCK.*.IBM Any IBM stock price on any exchange 20 The sample authorization entry below gives everyone assigned to the all group read privileges to all advisory topics. dn: cn=read,uid=activemq.advisory.\>,ou=topics,ou=destinations,o=amq,dc=example,dc=com objectclass: groupofuniquenames cn: read uniquemember: all 5 Camel You ll notice that the default ActiveMQ XML broker configuration file (activemq.xml) may come with the following sample Camel XML configuration. <camelcontext id="camel" xmlns=" <package>org.foo.bar</package> <route> <from uri="activemq:example.a"/> <to uri="activemq:example.b"/> </route> </camelcontext> The above configuration is not set up to work within a secure environment. That is, Camel establishes a connection with ActiveMQ, but does not provide a username and password. Therefore, when ActiveMQ security is enabled, the above configuration results in a security exception. The exception will be thrown multiple times, because Camel will continue to retry the connection. If you re not using Camel, comment out the above XML code. If you are using Camel, consult the Camel web site for information on how to configure Camel to establish ActiveMQ connections that provide a username and password.

23 6 Authentication and Authorization between Message Brokers 21 If you have enabled authentication for a particular message broker, then other brokers that wish to connect to that broker must provide the proper authentication credentials via their <networkconnector> element. For example, let s suppose that we have a network of brokers (NoB) with the following configuration: The NoB comprises two brokers (BrokerA and BrokerB) We have enabled authentication for BrokerA via the SP. Authentication for BrokerB has not been enabled. BrokerA only listens for connections. In other words, BrokerA has a <transportconnector> element, but no <networkconnector> elements. In order for BrokerB to connect to BrokerA, the corresponding <networkconnector> element in BrokerB s XML configuration file must be set up as follows. <networkconnectors> <!-- A connector used for connecting to brokera --> <networkconnector name="brokerabridge" username="user" password="password" uri="static://(tcp://brokera:61616)"/> </networkconnectors> Note how BrokerB s <networkconnector> element must provide the proper authentication credentials in order to connect to BrokerA. The username assigned to that <networkconnector> element must also have the proper authorization credentials if authorization has been enabled on BrokerA. Messages cannot be forwarded from BrokerB to BrokerA if BrokerA has authorization enabled and BrokerB s corresponding <networkconnector> element s username has not been given the proper authorization credentials. Also, if BrokerA is given a <networkconnector> element so that it can initiate a connection to BrokerB, then that <networkconnector> must also be given a username/password combination that is defined in BrokerA s SP security configuration file; this is required even though BrokerB does not have security services enabled.

24 7 JMX MBean LDAP Security Plugin for ActiveMQ 22 The SP includes an administrative MBean that displays a running SP s properties. The MBean also accepts the following commands. stop/start: The stop and start commands disable and enable the SP/security, respectively. When the plugin is disabled, authentication and authorization services are no longer active and the plugin stops checking the DS for authorization updates. stopauthorization/startauthorization: The stopauthorization and startauthorization commands disable and enable authorization, respectively. Please note that authorization is dependent on authentication being enabled. viewauthenticatorbean: Renders the property values for the AuthenticatorBean that is currently being used. The properties of the LdapConnectorBean that is wired to the AuthenticatorBean are also rendered. viewauthorizationmapbean: Renders the property values for the AuthorizationMapBean that is currently being used. The properties of the LdapConnectorBean that is wired to the AuthorizationMapBean are also rendered. testauthenticatorbean: Used to determine if the AuthenticatorBean can connect to the DS. testauthorizationmapbean: Used to determine if the AuthorizationMapBean can connect to the DS. refreshacl: Forces the SP to immediately connect to the DS and refresh its in-memory ACLs. The following are a series of images that illustrate the SP s MBean from within a JConsole session. The image below illustrates the SP s MBean, which is listed as TTM-LDAP Security-Plugin.

25 The image below illustrates how the SP s properties are displayed, via a Name-Value table, when the SP MBean is selected. The AclRefreshInterval property s value is mutable (that is why the 60 string is in bold), but please note that any new value entered will not be persisted out to the broker s XML configuration file. 23

26 This last image illustrates the plugin operations that can be performed via the MBean Abbreviations and Acronyms ACL DIT DN DS LDAP LDIF SP Access Control List Directory Information Tree Distinguished Name Directory Services or Server Lightweight Directory Access Protocol LDAP Data Interchange Format Security Plugin