LDAP-Benutzerregistrys mit dem Liberty-Profil konfigurieren
Sie können einen oder mehrere LDAP-Server (Lightweight Directory Access Protocol) zu Authentifizierungszwecken mit dem Liberty-Profil konfigurieren.
Vorbereitende Schritte
Informationen zu diesem Vorgang
Sie können einen vorhandenen LDAP-Server für die Anwendungsauthentifizierung im Liberty-Profil verwenden. Nehmen Sie dazu das Feature appSecurity-2.0 in die Datei server.xml auf, und geben Sie in der Datei server.xml das Feature ldapRegistry-3.0 und die Konfigurationsinformationen für die Verbindung mit einem LDAP-Server an.
Vorgehensweise
- Nehmen Sie die Liberty-Features appSecurity-2.0 und ldapRegistry-3.0 in die Datei server.xml auf.
- Optional: Fügen Sie zum Kommunizieren mit einem SSL-fähigen LDAP-Server das Liberty-Feature ssl-1.0 der Datei server.xml hinzu.
- Optional: Kopieren Sie den Truststore in das Serverkonfigurationsverzeichnis.
Sie können beispielsweise die Variable ${server.config.dir} verwenden.
Damit die SSL-Kommunikation mit dem LDAP-Server erfolgreich ist, muss das Unterzeichnerzertifikat für den LDAP-Server in den Truststore aufgenommen werden, auf den das Attribut sslAlias des Elements <ldapRegistry> verweist. In den folgenden Beispielen muss das Unterzeichnerzertifikat in den Truststore LdapSSLTrustStore.jks aufgenommen werden.
- Konfigurieren Sie den LDAP-Eintrag für den Server.
Wenn Sie SSL nicht für den LDAP-Server verwenden möchten, entfernen Sie in den folgenden Beispielen alle SSL- und Keystore-bezogenen Zeilen.
Sie konfigurieren den LDAP-Server in der Datei server.xml oder mithilfe von WebSphere Application Server Developer Tools for Eclipse. Auf der WASdev.net-Website finden Sie mehrere Sicherheitskonfigurationsbeispiele als Referenz bei der Konfiguration der Sicherheit Ihrer Anwendungen in Liberty Profile.- Für 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="(&(uid=%v)(objectclass=ePerson))" groupFilter="(&(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=" />
- Für 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="(&(sAMAccountName=%v)(objectcategory=user))" groupFilter="(&(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=" />
Fehler vermeiden:In diesem Beispiel muss die Groß-/Kleinschreibung in groupMemberIdMap="memberof:member" beachtet werden.
Wenn Sie WebSphere Application Server Developer Tools for Eclipse verwenden, wird das Kennwort bindPassword automatisch für Sie verschlüsselt. Wenn Sie die Datei server.xml direkt bearbeiten, können Sie den Befehl securityUtility encode zum Verschlüsseln des Kennworts bindPassword verwenden. Das Befehlszeilentool securityUtility ist im Verzeichnis $INSTALL_ROOT/bin verfügbar. Beim Ausführen des Befehls securityUtility encode können Sie das zu verschlüsselnde Kennwort entweder in der Befehlszeile eingeben, oder das Tool fordert Sie zur Eingabe des Kennworts auf, falls Sie keine Argumente angegeben haben. Anschließend gibt das Tool den verschlüsselten Wert aus. Kopieren Sie den vom Tool ausgegebenen Wert, und verwenden Sie diesen Wert für das Kennwort bindPassword.
- Für IBM® Directory Server:
- Optional: Konfigurieren Sie den Zertifikatsfiltermodus für den
LDAP-Server.
Weitere Informationen zum Modus für Zertifikatszuordnung im Liberty-Profil finden Sie unter LDAP-Zertifikatszuordnungsmodus.<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="(&(uid=%v)(objectclass=ePerson))" groupFilter="(&(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>
- Optional:
Sie können die Zuordnung zwischen LDAP-Attributen und dem Benutzerregistry-Attribut <externalId> definieren.
Sie können die Zuordnung zwischen LDAP-Attributen und dem Benutzerregistry-Attribut <externalId> definieren. Wenn Sie nach der Konfiguration der Zuordnung das Benutzerregistry-Attribut <externalId> für eine Operation verwenden, entspricht der Wert dem des zugeordneten LDAP-Attributs. Der folgende Beispielcode zeigt die Zuordnung, die für das Benutzerregistry-Attribut <externalId> zum LDAP-Attribut<distinguishedName> für den Entitätstyp <PersonAccount> definiert wurde. Das Attribut <autoGenerate> ist optional und der Attributwert ist standardmäßig 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>
- Optional: Konfigurieren Sie den Failover für mehrere LDAP-Server.
<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="(&(uid=%v)(objectclass=ePerson))" groupFilter="(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs)))" userIdMap="*:uid" groupIdMap="*:cn" groupMemberIdMap="ibm-allGroups:member;ibm-allGroups:uniqueMember; groupOfNames:member;groupOfUniqueNames:uniqueMember"> </idsLdapFilterProperties>
Weitere Informationen zu den Elementen ldapRegistry und failoverServers finden Sie unter Konfigurationselemente in der Datei 'server.xml'.
- Optional: Konfigurieren Sie mehrere LDAP-Registrys.
Sind in der Datei
server.xml mehrere Registrys konfiguriert, werden diese automatisch eingebunden. Stellen
Sie sicher, dass die Benutzer in allen eingebundenen Repositorys eindeutig sind. Andernfalls sind die Operationen der Benutzerregistry nicht erfolgreich. Anmerkung: Wenn Sie mehrere eingebundene LDAP-Repositorys verwenden, muss jedes Repository einen eindeutigen baseDN definieren.
<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>
Anmerkung:- Die Angabe des Elements federatedRepository ist nicht obligatorisch, damit mehrere LDAP-Registrys eingebunden werden, weil dies automatisch erfolgt. Wird das Element "federatedRepository" für die Konfiguration der Elemente participatingBaseEntry und primaryRealm angegeben, werden die Benutzerregistry-Operationen nur für die Repositorys ausgeführt, die im Element primaryRealm definiert sind. Die Zuordnungen der Eingabe- und Ausgabeeigenschaften für die verschiedenen Benutzerregistry-APIs können unter dem Element primaryRealm definiert werden.
- Das Attribut name des Elements participatingBaseEntry muss denselben Wert für das Attribut baseDN aufweisen wie das Element ldapRegistry. Im Beispiel weiter unten sind die Attribute baseDN und name für die LDAP-Registry auf dem Host ldapserver1.mycity1.mycompany.com konfiguriert. Der Wert des Attributs baseDN muss dem Wert des untergeordneten Baums in Ihrem LDAP-Server entsprechen, und der Wert des Attributs name muss mit dem Namen dieses untergeordneten Baumes in der eingebundenen Benutzerregistry übereinstimmen. Die Angabe des Attributs name ist optional. Standardmäßig verwendet das Attribut name denselben Wert wie das Attribut baseDN. Wenn das Attribut name im Element ldapRegistry angegeben wird, muss das Attribut name im Element participatingBaseEntry denselben Wert verwenden wie das Attribut name im Element 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>
Weitere Iinformationen zu eingebundenen ldapRegistry-Elementen finden Sie unter Konfigurationselemente in der Datei 'server.xml'.
- Optional: Sie können, wie im folgenden Beispiel, weitere optionale Attribute für die LDAP-Registry konfigurieren, z. B.
contextPool oder ldapCache:
<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>
Anmerkung:- Eine eingebundene Benutzerregistry verwendet den Kontextpoolmechanismus, um die Leistung beim gleichzeitigen Zugriff auf einen LDAP-Server zu verbessern. Kontextpooling findet auf einer höheren Ebene statt als Verbindungspooling. Jeder Kontexteintrag im Kontextpool entspricht einer Socketverbindung zum LDAP-Server. Die von diesem Pool verwendeten Bindungsberechtigungsnachweise werden beim Konfigurieren der LDAP-Registry angegeben.
- Das eingebundene Repository verwendet den Cachemechanismus zur Leistungsverbesserung. Informationen über die LDAP-Benutzer und -Gruppen werden auf der Basis der ausgeführten Benutzeroperationen zwischengespeichert. Wenn Sie z. B. eine Suchoperation für die LDAP-Benutzer und -Gruppen ausführen, wird das Ergebnis dieser Operation zwischengespeichert. Das Element ldapCache kann, wie im vorherigen Beispiel gezeigt, in der Datei server.xml aktiviert werden.
Tipp zur Fehlerbehebung: Zum Beheben von LDAP-Authentifizierungsproblemen verwenden Sie die folgenden Tracespezifikationen in der Datei bootstrap.properties:
com.ibm.ws.security.wim.*=all:com.ibm.websphere.security.wim.*=all
Untergeordnete Themen
- LDAP-Zertifikatszuordnungsmodus
Der Zertifikatszuordnungsmodus gibt an, ob X.509-Zertifikate in einem LDAP-Verzeichnis über EXACT_DN oder CERTIFICATE_FILTER im Liberty-Profil zugeordnet werden sollen.

Nutzungsbedingungen für Information Center | Feedback

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_sec_ldap
Dateiname: twlp_sec_ldap.html