Fix Pack 8550

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 the Liberty profile:
    • 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 the Liberty profile. 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 the Liberty profile.
      <WLP_HOME>\wlp\bin>securityUtility encode "liberty123"

      For more information about securing passwords, see Liberty profile: securityUtility command.

    • Basic user registry (supports multiple users and declaration of user groups).
      You can configure the Liberty profile 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 profile 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 the Liberty profile 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 for the Liberty profile.
  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.

    • 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"/>
    • Specify the user name and password by using the container managed authentication.
      The container managed authentication is applied when bindings specify an authentication alias for a resource reference of CONTAINER in the <res-auth> element. The following code example shows how the authentication can be specified.
      server.xml
      -------------
      <authData id="auth1" user="dbuser1" password="{xor}Oz0vKDtu"/>
        
       <jmsQueueConnectionFactory id="jndi/myQCF" jndiName="jndi/myQCF" 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>
       
       ibm-web-bnd.xml(web binding file)
       ----------------
        <resource-ref name="jndi/myQCF" binding-name="jndi/myQCF">
          <authentication-alias name="auth1"/>
        </resource-ref>
    After the configuration, the authenticated users can access the messaging resources.

Icon that indicates the type of topic Task topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Monday, 21 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-iseries&topic=twlp_msg_sec_authenticate
File name: twlp_msg_sec_authenticate.html