Versions Compared

Old Version 10

changes.mady.by.user Marnie McCormack

Saved on

compared with

New Version 11

changes.mady.by.user Martin Ritchie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added new security details

...

The connector section allows configuration of SSL and related keystore settings. By default this section is commented out and thus SSL is not enabled.

No Format
    <connector>
        <!-- Uncomment out this block and edit the keystorePath and keystorePassword
             to enable SSL support
        <ssl>
            <enabled>true</enabled>
            <sslOnly>true</sslOnly>
            <keystorePath>/path/to/keystore.ks</keystorePath>
            <keystorePassword>keystorepass</keystorePassword>
        </ssl>-->
        <qpidnio>true</qpidnio>
        <transport>nio</transport>
        <port>5672</port>
        <sslport>8672</sslport>
        <socketReceiveBuffer>32768</socketReceiveBuffer>
        <socketSendBuffer>32768</socketSendBuffer>
    </connector>

Management

This element allows the user to switch the connectivity of the management console on/off i.e. if the enabled tag is set to false you will not be able to connect a management console to this broker instance.

No Format
    <management>
        <enabled>true</enabled>
    </management>

Advanced

TBC

No Format
    <advanced>
       <filterchain enableExecutorPool="true"/>
        <enablePooledAllocator>false</enablePooledAllocator>
        <enableDirectBuffers>false</enableDirectBuffers>
        <framesize>65535</framesize>
        <compressBufferOnQueue>false</compressBufferOnQueue>
    </advanced>

Security

TBC

Principal databases

This section lists all the principal databases that are available for authentication. These databases understand what SASL mechanisms can be used against their data and so are responsible for registering these SASL mechanisms. Currently we do not provide means of limiting these mechanisms. The proposal was to allow the virtualhosts to specify which database and mechanisms they wished to use however as documented in virtualhosts below this is not possible as currently in AMQP authentication occurs before the selection of a virtualhost.

No Format

<principal-databases>
No Format

    <security>
        <principal-databases>database>
            <principal-database>
       <!-- A name for referencing this database-->
         <name>passwordfile</name>
<!-- The type of principal database -->            <class>org.apache.qpid.server.security.auth.PasswordFilePrincipalDatabase<database.PlainPasswordVhostFilePrincipalDatabase</class>
        <!-- Any attributes associated with the database. Here it is a password file to load. -->
        <attributes>
            <attribute>
        <attribute>        <name>passwordFile</name>
                <value>${conf}/passwdVhost</value>
        <name>passwordFile</name>    </attribute>
        </attributes>
    </principal-database>

    <principal-database>
        <value>${conf}/passwd</value>
<name>md5passwordfile</name>
        <class>org.apache.qpid.server.security.auth.database.MD5PasswordFilePrincipalDatabase</class>
        <attributes>
            <attribute>
                <<name>passwordFile</attribute>name>
                </attributes><value>${conf}/md5passwd</value>
            </principal-database>attribute>
        </attributes>
    </principal-database>
</principal-databases>

Virtualhosts

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

No Format

<virtualhosts>
    <virtualhost>
    <sasl>
    <name>localhost</name>
        <localhost>
      <mechanisms>
      <store>
          <mechanism>
      <!--class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
              <initialiser>
          <environment-path>${work}/bdb/localhost-store</environment-path-->
                <class>org.apache.qpid.server.securitystore.auth.CRAMMD5Initialiser<MemoryMessageStore</class>
            </store>

            <principal-database>passwordfile</principal-database><security>
                <!-- Need protocol changes to allow this-->
                <authentication>
                    <<name>passwordfile</initialiser>name>
                    <!-- Currently this can't be used as Vhost isn't specified at connection start only connection open -->
                    <mechanism>PLAIN</mechanism>
                <mechanism></authentication>
                
     <initialiser>
           <access>
                    <!-- This is the type of AccessManager to use.-->
                    <class>org.apache.qpid.server.security.authaccess.amqplain.AmqPlainInitialiser<PrincipalDatabaseAccessManager</class>
                    <attributes>
                 <principal-database>passwordfile</principal-database>
       <attribute>
                            <name>principalDatabase</name>
                           < <value>passwordfile</initialiser>value>
                        </mechanism>
attribute>
                      <mechanism>
  <attribute>
                           <initialiser>
 <!-- The defaultAccessManager can be either DenyAll or AllowAll -->
                           <class>org.apache.qpid.server.security.auth.plain.PlainInitialiser</class> <name>defaultAccessManager</name>
                        <principal-database>passwordfile</principal-database>    <value>DenyAll</value>
                        </initialiser>attribute>
                    </mechanism>attributes>
                </mechanisms>access>
        </sasl>
    </security>

Virtualhosts

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

No Format

	<virtualhosts>
		<virtualhost>
			<name>localhost</name>
			<localhost>
			    <store>
					<!--class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
					<environment-path>${work}/bdb/localhost-store</environment-path-->
					<class>org.apache.qpid.server.store.MemoryMessageStore</class>
			    </store>		
			</localhost>
		    </virtualhost>
		
		<virtualhost>
			
    <virtualhost>
        <name>development</name>
			<development>
			        <development>
            <store>
					                <class>org.apache.qpid.server.store.MemoryMessageStore</class>		
			
            </store>			
			
        </development>
		    </virtualhost>
		
		<virtualhost>
			
    <virtualhost>
        <name>test</name>
			<test>
			        <test>
            <store>
					                <class>org.apache.qpid.server.store.MemoryMessageStore</class>
			            </store>			
			
        </test>
		    </virtualhost>
		
	</virtualhosts>

Heartbeat

The Qpid broker sends an internal (only) heartbeat. This element allows configuration of the frequency of this heartbeat. At present, we recommend that you leave this section unchanged !

No Format
    <heartbeat>
        <delay>0</delay>
        <timeoutFactor>2.0</timeoutFactor>
    </heartbeat>

Queue

This should NOT be changed lightly as it sets the broker up to automatically bind queues to exchanges.

It could theoretically be used to prevent users creating new queues at runtime, assuming that you have created all queues/topics etc at broker startup. However, best advice is to leave unchanged for now.

No Format
    <queue>
        <auto_register>true</auto_register>
    </queue>

Virtualhosts

This element allows you to specify a location for the virtualhosts.xml file that you wish to use. If you are not using a subdirectory under $QPID_HOME you can provide a fully qualified path instead.

No Format
    <virtualhosts>${conf}/virtualhosts.xml</virtualhosts>