Configuration de registres d'utilisateurs LDAP dans Liberty

Vous pouvez configurer un ou plusieurs serveurs LDAP (Lightweight Directory Access Protocol) avec Liberty pour l'authentification.

Avant de commencer

Assurez-vous que votre serveur LDAP est déjà opérationnel et en cours d'exécution. Vous devez également connaître son nom d'hôte et son numéro de port.

Pourquoi et quand exécuter cette tâche

Vous pouvez utiliser un serveur LDAP existant pour l'authentification des applications sur Liberty. Pour ceci, vous devez ajouter la fonction appSecurity-2.0 au fichier server.xml et spécifier dans le fichier server.xml la fonction ldapRegistry-3.0 ainsi que les informations de configuration pour la connexion au serveur LDAP.

Eviter les incidents : Le site Web WASdev.net propose plusieurs exemples de configuration de sécurité pour votre référence lorsque vous configurez la sécurité pour vos applications dans Liberty.Pour plus d'informations, suivez dans les références connexes le lien vers la configuration de fragments.

Procédure

  1. Ajoutez les fonctions Liberty appSecurity-2.0 et ldapRegistry-3.0 au fichier server.xml.
  2. Facultatif : Pour communiquer avec un serveur LDAP pouvant utiliser SSL, ajoutez la fonction Liberty ssl-1.0 dans le fichier server.xml.
  3. Facultatif : Copiez le fichier de clés certifiées dans le répertoire de configuration du serveur. Par exemple, vous pouvez utiliser la variable ${server.config.dir}.

    Pour que la communication SSL soit possible avec un serveur LDAP, le certificat de signataire de ce dernier doit être ajouté au fichier de clés certifiées qui est désigné par l'attribut sslAlias de l'élément <ldapRegistry>. Dans les exemples suivants, le certificat de signataire doit être ajouté au fichier LdapSSLTrustStore.jks.

  4. Configurez l'entrée LDAP pour le serveur.

    Si vous ne voulez pas activer la communication SSL pour le serveur LDAP, supprimez toutes les lignes relatives à SSL et au fichier de clés des exemples ci-après.

    Le serveur LDAP est configuré dans le fichier server.xml ou à l'aide des outils WebSphere Application Server Developer Tools for Eclipse. Le site Web WASdev.net propose plusieurs exemples de configuration de sécurité pour votre référence lorsque vous configurez la sécurité pour vos applications dans Liberty.
    • Pour IBM® Directory Server :
      <ldapRegistry id="ldap" realm="SampleLdapIDSRealm" 
          host="ldapserver.mycity.mycompany.com" port="389" ignoreCase="true" 
          baseDN="o=mycompany,c=us" 
          ldapType="IBM Tivoli Directory Server"
          sslEnabled="true" 
          sslRef="LDAPSSLSettings">
          <idsFilters
          	userFilter="(&amp;(uid=%v)(objectclass=ePerson))" 
          	groupFilter="(&amp;(cn=%v)(|(objectclass=groupOfNames)
                           (objectclass=groupOfUniqueNames)
      		     (objectclass=groupOfURLs)))"
          	userIdMap="*:uid" 
          	groupIdMap="*:cn" 
          	groupMemberIdMap="mycompany-allGroups:member;mycompany-allGroups:uniqueMember;
      			  groupOfNames:member;groupOfUniqueNames:uniqueMember">
          </idsFilters>    
      </ldapRegistry>
      <ssl id="LDAPSSLSettings" keyStoreRef="LDAPKeyStore" trustStoreRef="LDAPTrustStore" /> 
      
      <keyStore id="LDAPKeyStore" location="${server.config.dir}/LdapSSLKeyStore.jks" 
           type="JKS" password="{xor}CDo9Hgw=" /> 
      <keyStore id="LDAPTrustStore" location="${server.config.dir}/LdapSSLTrustStore.jks" 
          type="JKS" password="{xor}CDo9Hgw=" />   
    • Pour Microsoft Active Directory Server :
      <ldapRegistry id="ldap" realm="SampleLdapADRealm" 
          host="ldapserver.mycity.mycompany.com" port="389" ignoreCase="true" 
          baseDN="cn=users,dc=adtest,dc=mycity,dc=mycompany,dc=com" 
          bindDN="cn=testuser,cn=users,dc=adtest,dc=mycity,dc=mycompany,dc=com" 
          bindPassword="testuserpwd"
          ldapType="Microsoft Active Directory" 
          sslEnabled="true" 
          sslRef="LDAPSSLSettings"> 
          <activedFilters
          userFilter="(&amp;(sAMAccountName=%v)(objectcategory=user))"
      groupFilter="(&amp;(cn=%v)(objectcategory=group))" 
         userIdMap="user:sAMAccountName" 
          groupIdMap="*:cn" 
          groupMemberIdMap="memberOf:member" >
      </activedFilters>
          </ldapRegistry>
      
      <ssl id="LDAPSSLSettings" keyStoreRef="LDAPKeyStore" trustStoreRef="LDAPTrustStore" /> 
      
      <keyStore id="LDAPKeyStore" location="${server.config.dir}/LdapSSLKeyStore.jks" 
                type="JKS" password="{xor}CDo9Hgw=" /> 
      <keyStore id="LDAPTrustStore" location="${server.config.dir}/LdapSSLTrustStore.jks" 
                type="JKS" password="{xor}CDo9Hgw=" />  

    Si vous utilisez WebSphere Application Server Developer Tools for Eclipse, le mot de passe bindPassword est codé pour vous automatiquement. Si vous éditez le fichier server.xml directement, vous pouvez utiliser la commande securityUtility encode pour coder le mot de passe bindPassword. L'outil de ligne de commande securityUtility est disponible dans le répertoire $INSTALL_ROOT/bin. Lorsque vous exécutez la commande securityUtility encode, vous spécifiez le mot de passe à coder en tant qu'entrée sur la ligne de commande ou, si aucun argument n'est spécifié, l'outil vous invite à le spécifier. Celui-ci génère alors la valeur codée. Copiez la valeur générée par l'outil et utilisez-la pour le mot de passe bindPassword.

  5. Facultatif : Configurez le mode de filtrage des certificats pour le serveur LDAP.
    <ldapRegistry id="LDAP" realm="SampleLdapIDSRealm" 
          host="myldap.ibm.com" port="389" ignoreCase="true" 
          baseDN="o=ibm,c=us" 
          ldapType="IBM Tivoli Directory Server" searchTimeout="8m"
          certificateMapMode="CERTIFICATE_FILTER" 
          certificateFilter="uid=${SubjectCN}"> 
          <idsFilters
          userFilter="(&amp;(uid=%v)(objectclass=ePerson))" 
          groupFilter="(&amp;(cn=%v)(|(objectclass=groupOfNames)
              (objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))" 
          userIdMap="*:uid" 
          groupIdMap="*:cn" 
          groupMemberIdMap="ibm-allGroups:member;ibm-allGroups:uniqueMember;
              groupOfNames:member;groupOfUniqueNames:uniqueMember">
    </idsFilters>
          </ldapRegistry>
    Pour plus d'informations sur le mode de mappage des certificats dans Liberty, voir Mode de mappage des certificats LDAP.
  6. Facultatif : Vous pouvez définir le mappage entre les attributs LDAP et les attributs de schéma du registre d'utilisateurs.

    Une fois le mappage configuré, si vous utilisez l'attribut du registre d'utilisateurs pour une opération pour laquelle le mappage est défini, la valeur d'attribut du registre d'utilisateurs correspondra à la valeur de l'attribut LDAP. Dans l'exemple suivant, vous pouvez voir que le mappage est défini pour l'attribut LDAP <userPassword> avec la propriété de registre d'utilisateurs <password> dans le fichier server.xml. L'attribut <defaultValue> est facultatif.

    <ldapRegistry id="LDAP" realm="SampleLdapIDSRealm" 
          host="myldap.ibm.com" port="389" ignoreCase="true" 
          baseDN="o=ibm,c=us" 
          ldapType="IBM Tivoli Directory Server" searchTimeout="8m">
          <attributeConfiguration>
                 <attribute name="userPassword" propertyName="password" entityType="PersonAccount" defaultValue="xyz123"/>
          </attributeConfiguration>
    </ldapRegistry>
  7. Facultatif : Vous pouvez définir un mappage entre les attributs LDAP et l'attribut <externalId> du registre utilisateurs.

    Vous pouvez définir un mappage entre les attributs LDAP et l'attribut <externalId> du registre utilisateurs. Une fois le mappage configuré, lorsque vous utiliserez l'attribut <externalId> du registre utilisateurs, sa valeur sera équivalente à celle de l'attribut LDAP mappé. L'exemple de code suivant illustre le mappage défini pour l'attribut <externalId> du registre utilisateurs avec l'attribut LDAP <distinguishedName> pour le type d'entité <PersonAccount>. L'attribut <autoGenerate> est facultatif et sa valeur par défaut est 'false'.

    <ldapRegistry id="LDAP" realm="SampleLdapIDSRealm" 
          host="myldap.ibm.com" port="389" ignoreCase="true" 
          baseDN="o=ibm,c=us" 
          ldapType="IBM Tivoli Directory Server" searchTimeout="8m">
          <attributeConfiguration>
                 <externalIdAttribute name="distinguishedName" entityType="PersonAccount" autoGenerate="false"></externalIdAttribute>
          </attributeConfiguration>
    </ldapRegistry>
  8. Facultatif : Configurez la reprise par basculement si vous avez plusieurs serveurs LDAP.
    <ldapRegistry id="LDAP" realm="SampleLdapIDSRealm"
        	host="ldapserver1.mycity.mycompany.com" port="389" ignoreCase="true"
         	baseDN="o=ibm,c=us" ldapType="IBM Tivoli Directory Server" idsFilters="ibm_dir_server">
    	<failoverServers name="failoverLdapServersGroup1">
    		<server host="ldapserver2.mycity.mycompany.com" port="389" />
    		<server host="ldapserver3.mycity.mycompany.com" port="389" />
    	</failoverServers>
    	<failoverServers name="failoverLdapServersGroup2">
    		<server host="ldapserver4.mycity.mycompany.com" port="389" />
    	</failoverServers>
    </ldapRegistry>
    
    <idsLdapFilterProperties id="ibm_dir_server"
    	    userFilter="(&amp;(uid=%v)(objectclass=ePerson))"
    	    groupFilter="(&amp;(cn=%v)(|(objectclass=groupOfNames)
                     (objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))"
    	    userIdMap="*:uid" groupIdMap="*:cn"
    	    groupMemberIdMap="ibm-allGroups:member;ibm-allGroups:uniqueMember;
                          groupOfNames:member;groupOfUniqueNames:uniqueMember">
    </idsLdapFilterProperties>

    Pour plus d'informations sur les éléments ldapRegistry et failoverServers, consultez LDAP User Registry.

  9. Facultatif : Configurez plusieurs registres LDAP. Si plusieurs registres LDAP sont configurés dans le fichier server.xml, ils sont fédérés automatiquement. Vérifiez que les utilisateurs sont uniques dans tous les référentiels fédérés, sinon les opérations de registre utilisateur n'aboutissent pas.
    Remarque : Lorsque vous utilisez plusieurs référentiels fédérés LDAP, chaque référentiel doit définir un nom baseDN unique.
    <ldapRegistry host="ldapserver1.mycity1.mycompany.com" baseDN="o=mycompany,c=us"
        port="123" ldapType="IBM Tivoli Directory Server"> 
    </ldapRegistry>
    
    <ldapRegistry host="ldapserver2.mycity2.mycompany.com" 
        baseDN="cn=users,dc=secfvt2,dc=mycity2,dc=mycompany,dc=com" 
        port="456"
        ldapType="Microsoft Active Directory" 
        bindDN="cn=testuser,cn=users,dc=secfvt2,dc=mycity2,dc=mycompany,dc=com" 
        bindPassword="{xor}KzosKyosOi0vKDs=">
    </ldapRegistry>
    Remarque :
    • La spécification de l'élément federatedRepository n'est pas obligatoire pour fédérer plusieurs registres LDAP car ces derniers sont fédérés automatiquement. Si l'élément federatedRepository est spécifié pour la configuration des éléments participatingBaseEntry et primaryRealm, les appels d'opérations de registre d'utilisateurs ne sont effectués que sur les référentiels définis dans l'élément primaryRealm. Vous pouvez définir les mappages de propriétés d'entrée et de sortie pour différents API de registre utilisateur sous l'élément primaryRealm.
    • L'attribut name de l'élément participatingBaseEntry doit être identique à la valeur de l'attribut baseDN spécifiée dans l'élément ldapRegistry. Dans l'exemple suivant, les attributs baseDN et name sont configurés pour le registre LDAP sur l'hôte ldapserver1.mycity1.mycompany.com. La valeur de l'attribut baseDN doit être identique à celle qui figure dans la sous-arborescence de votre serveur LDAP, et la valeur de l'attribut name doit être le nom de cette sous-arborescence dans le registre d'utilisateurs fédéré. Il n'est pas nécessaire de spécifier l'attribut name. Par défaut, il utilise la même valeur que l'attribut baseDN. Si l'attribut name est spécifié dans l'élément ldapRegistry, l'attribut name de l'élément participatingBaseEntry doit utiliser la même valeur que l'attribut name dans l'élément ldapRegistry.
    <ldapRegistry host="ldapserver1.mycity1.mycompany.com" baseDN="o=mycompany,ou=myou,c=us"
        port="123" ldapType="IBM Tivoli Directory Server" name="o=mybaseentry"> 
    </ldapRegistry>
    
    <ldapRegistry host="ldapserver2.mycity2.mycompany.com" 
        baseDN="cn=users,dc=secfvt2,dc=mycity2,dc=mycompany,dc=com" 
        port="456"
        ldapType="Microsoft Active Directory" 
        bindDN="cn=testuser,cn=users,dc=secfvt2,dc=mycity2,dc=mycompany,dc=com" 
        bindPassword="{xor}KzosKyosOi0vKDs=">
    </ldapRegistry>
    
    <federatedRepository>
    	 <primaryRealm name="RealmName" delimiter="@" allowOpIfRepoDown="true">
    	 	<participatingBaseEntry name="o=mybaseentry"/>
    		 <participatingBaseEntry name="cn=users,dc=secfvt2,dc=mycity2,dc=mycompany,dc=com"/>
    	 	 <uniqueUserIdMapping inputProperty="uniqueName" outputProperty="uniqueName"/>
    	 	 <userSecurityNameMapping inputProperty="principalName" outputProperty="principalName"/>
            		 <userDisplayNameMapping inputProperty="principalName" outputProperty="principalName"/>
    		 <uniqueGroupIdMapping inputProperty="uniqueName" outputProperty="uniqueName"/>
            		 <groupSecurityNameMapping inputProperty="cn" outputProperty="cn"/>
            		 <groupDisplayNameMapping inputProperty="cn" outputProperty="cn"/>
            	</primaryRealm>
    </federatedRepository>

    Pour plus d'informations sur les éléments ldapRegistry fédérés, consultez LDAP User Registry.

  10. Facultatif : Vous pouvez configurer les autres attributs facultatifs pour le registre LDAP, comme contextPool ou ldapCache, comme indiqué dans l'exemple suivant :
    <ldapRegistry id="IBMDirectoryServerLDAP"         realm="SampleLdapIDSRealm"
            host="host.domain.com" port="389" ignoreCase="true"
            baseDN="o=domain,c=us"
            bindDN="cn=testuser,o=domain,c=us"
            bindPassword="mypassword"
            ldapType="IBM Tivoli Directory Server"
            searchTimeout="8m">
        <contextPool enabled="true" initialSize="1" maxSize="0" timeout="0s" waitTime="3000ms" preferredSize="3"/>
        <ldapCache>
            <attributesCache size="4000" timeout="1200s" enabled="true" sizeLimit="2000"/>
            <searchResultsCache size="2000" timeout="600s" enabled="true" resultsSizeLimit="1000"/>
        </ldapCache>
    </ldapRegistry>
    Remarque :
    • Le registre d'utilisateurs fédéré utilise le mécanisme de mise en pool des contextes pour améliorer les performances de l'accès simultané à un serveur LDAP. La mise en pool des contextes fonctionne à un niveau plus élevé que la mise en pool des connexions. Chaque entrée de contexte dans le pool de contextes correspond à une connexion socket au serveur LDAP. Les droits d'accès de liaison utilisés par ce pool sont spécifiés lorsque vous configurez le registre LDAP.
    • Le référentiel fédéré utilise le mécanisme de cache pour améliorer les performances. Il met en cache des informations sur les utilisateurs LDAP et des groupes basés sur les opérations utilisateur effectuées. Par exemple, si vous effectuez une opération de recherche sur les utilisateurs LDAP et groupes, le résultat de l'opération est en cache. Vous pouvez activer l'élément ldapCache dans le fichier server.xml comme montré dans l'exemple précédent.
    Conseil pour l'identification des incidents : Pour résoudre les problèmes d'authentification LDAP, utilisez les spécifications de trace suivants du fichier bootstrap.properties :
    com.ibm.ws.security.wim.*=all:com.ibm.websphere.security.wim.*=all

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_sec_ldap.html