Menu Search

Chapter 11. Security

11.1. Authentication Providers

In order to successfully establish a connection to the Java Broker, the connection must be authenticated. The Java Broker supports a number of different authentication schemes, each with its own "authentication provider". Any number of Authentication Providers can be configured on the Broker at the same time.

The Authentication Providers can be configured using REST Management interfaces and Web Management Console.

The following Authentication Provider managing operations are available from Web Management Console:

  • A new Authentication Provider can be added by clicking onto "Add Provider" on the Broker tab.

  • An Authentication Provider details can be viewed on the Authentication Provider tab. The tab is displayed after clicking onto Authentication Provider name in the Broker object tree or after clicking onto Authentication Provider row in Authentication Providers grid on the Broker tab.

  • Editing of Authentication Provider can be performed by clicking on "Edit" button on Authentication Provider tab.

  • An existing Authentication Provider can be deleted by clicking on "Delete Provider" button on Broker tab or "Delete" button on the Authentication Provider tab.

The Authentication Provider type and name cannot be changed for existing providers as editing of name and type is unsupported at the moment. Only provider specific attributes can be modified in the editing dialog and stored in the broker configuration store.

Important

Only unused Authentication Provider can be deleted. For delete requests attempting to delete Authentication Provider associated with the Ports, the errors will be returned and delete operations will be aborted. It is possible to change the Authentication Provider on Port at runtime. However, the Broker restart is required for changes on Port to take effect.

11.1.1. Simple LDAP Authentication Provider

SimpleLDAPAuthenticationProvider authenticates connections against a Directory (LDAP).

To create a SimpleLDAPAuthenticationProvider the following mandatory fields are required:

  • LDAP server URL is the URL of the server, for example, ldaps://example.com:636

  • Search context is the distinguished name of the search base object. It defines the location from which the search for users begins, for example, dc=users,dc=example,dc=com

  • Search filter is a DN template to find an LDAP user entry by provided user name, for example, (uid={0})

Additionally, the following optional fields can be specified:

  • LDAP context factory is a fully qualified class name for the JNDI LDAP context factory. This class must implement the InitialContextFactory interface and produce instances of DirContext. If not specified a default value of com.sun.jndi.ldap.LdapCtxFactory is used.

  • LDAP authentication URL is the URL of LDAP server for performing "ldap bind". If not specified, the LDAP server URL will be used for both searches and authentications.

  • Truststore name is a name of configured truststore. Use this if connecting to a Directory over SSL (i.e. ldaps://) which is protected by a certificate signed by a private CA (or utilising a self-signed certificate).

Important

In order to protect the security of the user's password, when using LDAP authentication, you must:
  • Use SSL on the broker's AMQP, JMX, and HTTP ports to protect the password during transmission to the Broker.

  • Authenticate to the Directory using SSL (i.e. ldaps://) to protect the password during transmission from the Broker to the Directory.

The LDAP Authentication Provider works in the following manner. It first connects to the Directory anonymously and searches for the ldap entity which is identified by the username. The search begins at the distinguished name identified by Search Context and uses the username as a filter. The search scope is sub-tree meaning the search will include the base object and the subtree extending beneath it.

If the search returns a match, the Authentication Provider then attempts to bind to the LDAP server with the given name and the password. Note that simple security authentication is used so the Directory receives the password in the clear.

11.1.2. Kerberos

Kereberos Authentication Provider uses java GSS-API SASL mechanism to authenticate the connections.

Configuration of kerberos is done through system properties (there doesn't seem to be a way around this unfortunately).

    export JAVA_OPTS=-Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=qpid.conf
    ${QPID_HOME}/bin/qpid-server
  

Where qpid.conf would look something like this:

com.sun.security.jgss.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    doNotPrompt=true
    realm="EXAMPLE.COM"
    useSubjectCredsOnly=false
    kdc="kerberos.example.com"
    keyTab="/path/to/keytab-file"
    principal="<name>/<host>";
};

Where realm, kdc, keyTab and principal should obviously be set correctly for the environment where you are running (see the existing documentation for the C++ broker about creating a keytab file).

Note: You may need to install the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" appropriate for your JDK in order to get Kerberos support working.

Since Kerberos support only works where SASL authentication is available (e.g. not for JMX authentication) you may wish to also include an alternative Authentication Provider configuration, and use this for JMX and HTTP ports.

11.1.3. External (SSL Client Certificates)

When requiring SSL Client Certificates be presented the External Authentication Provider can be used, such that the user is authenticated based on trust of their certificate alone, and the X500Principal from the SSL session is then used as the username for the connection, instead of also requiring the user to present a valid username and password.

Note: The External Authentication Provider should typically only be used on the AMQP ports, in conjunction with SSL client certificate authentication. It is not intended for other uses such as the JMX management port and will treat any non-sasl authentication processes on these ports as successful with the given username. As such you should configure another Authentication Provider for use on non-AMQP ports. Perhaps the only exception to this would be where the broker is embedded in a container that is itself externally protecting the HTTP interface and then providing the remote users name.

On creation of External Provider the use of full DN or username CN as a principal name can be configured. If field "Use the full DN as the Username" is set to "true" the full DN is used as an authenticated principal name. If field "Use the full DN as the Username" is set to "false" the user name CN part is used as the authenticated principal name. Setting the field to "false" is particular useful when ACL is required, as at the moment, ACL does not support commas in the user name.

11.1.4. Anonymous

The Anonymous Authentication Provider will allow users to connect with or without credentials and result in their identification on the broker as the user ANONYMOUS. This Provider does not require specification of any additional fields on creation.

11.1.5. Plain Password File

The PlainPasswordFile Provider uses local file to store and manage user credentials. When creating an authentication provider the path to the file needs to be specified. If specified file does not exist an empty file is created automatically on Authentication Provider creation. On Provider deletion the password file is deleted as well. For this Provider user credentials can be added, removed or changed using REST management interfaces and web management console.

On navigating to the Plain Password File Provider tab (by clicking onto provider name from Broker tree or provider row in providers grid on Broker tab) the list of existing credentials is displayed on the tab with the buttons "Add User" and "Delete Users" to add new user credentials and delete the existing user credentials respectively. On clicking into user name on Users grid the pop-up dialog to change the password is displayed.

11.1.5.1. Plain Password File Format

The user credentials are stored on the single file line as user name and user password pairs separated by colon character.

# password file format
# <user name>: <user password>
guest:guest
        

11.1.6. Base64MD5 Password File

Base64MD5PasswordFile Provider uses local file to store and manage user credentials similar to Similar to PlainPasswordFile but instead of storing a password the MD5 password digest encoded with Base64 encoding is stored in the file. When creating an authentication provider the path to the file needs to be specified. If specified file does not exist an empty file is created automatically on Authentication Provider creation. On Base64MD5PasswordFile Provider deletion the password file is deleted as well. For this Provider user credentials can be added, removed or changed using REST management interfaces and web management console.

On navigating to the Base64MD5PasswordFile Provider tab (by clicking onto provider name from Broker tree or provider row in providers grid on Broker tab) the list of existing credentials is displayed on the tab with the buttons "Add User" and "Delete Users" to add new user credentials and delete the existing user credentials respectively. On clicking into user name on Users grid the pop-up dialog to change the password is displayed.