Authenticating users to connect to the messaging engine

You must validate the users credentials so that the user is authenticated to connect to the messaging engine.

Procedure

  1. Configure the user registry.
    The following types of registry are supported in Liberty:
    • QuickStartSecurity (supports only one user).

      This option is the simplest way of specifying a username and password to authenticate the application connections. You can use the <quickStartSecurity> element to enable a simple (one user) security setup for Liberty. Define the following <quickStartSecurity> element in the server.xml file.

      In the following example, the <quickStartSecurity> element is used to define a single user, named liberty, with a password of liberty123.
      <quickStartSecurity userName="liberty" userPassword="liberty123"/>
      Note: Ensure that the raw password is not specified (for example, liberty123) in the server.xml file. To encode the password, use the security utility tool available with Liberty.
      <WLP_HOME>\wlp\bin>securityUtility encode "liberty123"

      For more information about securing passwords, see securityUtility command.

    • Basic user registry (supports multiple users and declaration of user groups).
      You can configure Liberty to authenticate and authorize users by using the basic user registry. You can set up a basic user registry and configure multiple role mapping in the server.xml file for a Liberty server.
      Note: The configuration of the <basicRegistry> overrides the <quickStartSecurity> registry.
      <basicRegistry id="basic" realm="customRealm">
      	<user name="user1" password="user1pwd" />
      	<user name="user2" password="user2pwd" />
      	<user name="user3" password="user3pwd" />
      	<user name="user4" password="user4pwd" />
      	<user name="user5" password="user5pwd" />
      	<user name="user6" password="user6pwd" />
      	<user name="user7" password="user7pwd" />
      	<user name="user8" password="user8pwd" />
      	<group name="Developers">
      		<member name="user2" />
      		<member name="user4" />
      	</group>
      	<group name="Testers">
      		<member name="user8" />
      		<member name="user7" />
      	</group>
      </basicRegistry>
    • Lightweight Directory Access Protocol (LDAP) registries (external registries such as Microsoft Active Directory and IBM Directory Server).
      You can configure an LDAP server with Liberty for authentication.
      <ldapRegistry id="LDAP" realm="SampleLdapIDSRealm" host="ctldap1.austin.ibm.com" port="389"
          ignoreCase="true" baseDN="o=ibm,c=us" 
          ldapType="IBM Tivoli Directory Server" 
          idsFilters="ibm_dir_server" 
          searchTimeout="8m"> 
              <failoverServers name="failoverLdapServers"> 
              	<server host="ralwang.rtp.raleigh.ibm.com" port="389"/>  
              </failoverServers> 
      </ldapRegistry>
      Notes:
      • Any user name and password that is specified in the LDAP registry can be specified in the connection factory.
      • You can define only one registry type in the server.xml file (either a basic registry or an LDAP registry).
    For more information about configuring registries, see Configuring a user registry in Liberty.
  2. Configuring the application authentication.
    Based on the user registry that is specified in the server.xml file, you can configure your application in the following ways:
    • Specify the user name and password in JMS resources (that is the connection factory and activation specification properties).
      The application that uses the connection factory is authenticated against the user name and password specified in the connection factory.
      <jmsQueueConnectionFactory jndiName="myQCF" connectionManagerRef="ConMgr4">
      	<properties.wasJms userName="liberty" password="liberty123"       
      		remoteServerAddress="localhost:7276:BootstrapBasicMessaging">
      	</properties>
      </jmsQueueConnectionFactory>
      <connectionManager id="ConMgr4" maxPoolSize="2"/>

      In the previous example, the application that looks for the myQCF queue connection factory is automatically authenticated against the user name liberty and password liberty123 that is defined for the configured registry.

      Note: The specified connection property looks up myQCF in the path jms/myQCF and not in the java:comp/env/jms/myQCF path.
    • Specifying the user name and password in the JMS application.
      Note: The user name and password that are specified in the JMS application overrides the user name and password defined in the connection factory.
      The application looks up the connection factory property and passes the username and password to authenticate the credentials.
      server.xml
      --------------------
      <jmsQueueConnectionFactory jndiName="myQCF" connectionManagerRef="ConMgr4">
      	<properties.wasJms 
      		remoteServerAddress="localhost:7276:BootstrapBasicMessaging">
      	</properties>
      </jmsQueueConnectionFactory>
      <connectionManager id="ConMgr4" maxPoolSize="2"/>
      
      Application snippets
      ------------------
      QueueConnectionFactory qcf = (QueueConnectionFactory) new InitialContext().lookup("myQCF");
      QueueConnection qCon = qcf.createQueueConnection("liberty", "liberty123");
    • Specify the user name and password in the <containerAuthDataRef> element.
      The default authentication data for the container managed authentication is applicable when bindings do not specify an authentication alias for the resource reference with res-auth=CONTAINER. The <authData> element must be defined and must be referenced by the service integration bus resources as follows:
      
      <authData id="auth1" user="liberty" password="liberty123"/>
      
      <jmsQueueConnectionFactory jndiName="myQCF" 
      	containerAuthDataRef="auth1" connectionManagerRef="ConMgr4">
            <properties.wasJms/>
      </jmsQueueConnectionFactory>
      <connectionManager id="ConMgr4" maxPoolSize="2"/>
      
       web.xml
       ----------
         <resource-ref>
          <res-ref-name>jndi/myQCF</res-ref-name>
          <res-auth>Container</res-auth>
          <res-type>javax.jms.QueueConnectionFactory</res-type>
          <lookup-name>jndi/myQCF</lookup-name>
        </resource-ref>
    After the configuration, the authenticated users need to be assigned the required roles in order to access the messaging resources securely. See Authorizing users to connect to the messaging engine.