IBM HTTP Server per WebSphere Application Server, Versione 6.1
             Sistemi operativi: AIX, HP-UX, Linux, Solaris, Windows

             Personalizzare la tabella dei contenuti e ricercare i risultati

Autenticazione con LDAP su IBM HTTP Server (sistemi distribuiti)

In questa sezione viene descritto come configurare LDAP per proteggere i file su IBM HTTP Server.

Prima di iniziare

La direttiva LoadModule per LDAP non è caricata in IBM HTTP Server per impostazione predefinita. Senza la direttiva LoadModule, le funzioni LDAP non sono disponibili. Per abilitarla, aggiungere una direttiva LoadModule al file di IBM HTTP Server httpd.conf nel modo seguente:

Se sul computer è installato un client LDAP, è possibile utilizzare ldapsearch come strumento per verificare i valori che si intende utilizzare per le diverse impostazioni.

Informazioni su questa attività

Consultare Direttive LDAP per descrizioni dettagliate delle direttive LDAP (mod_ibm_ldap).

Procedura

  1. Modificare il file di configurazione httpd.conf di IBM HTTP Server.
  2. Determinare la risorsa a cui si intende limitare l'accesso. Ad esempio: <Directory "/secure_info">.
  3. Aggiungere direttive in httpd.conf alla posizione della directory (contenitore) da proteggere con valori specifici dell'ambiente. Ad esempio:
    • LdapConfigFile path_to_ldap.prop
    • AuthType Basic
    • AuthName "Titolo del dominio protetto"
    • Require valid-user
  4. Esistono tre opzioni su come usare IBM HTTP Server per autenticarlo con l'installazione di un LDAP esistente.
    • Autorizzazione basata sull'appartenenza al gruppo LDAP.
      Utilizzare LDAP per verificare le password utente e l'esistenza dell'utente in un gruppo definito all'interno di LDAP.
      Nota: L'appartenenza che identifica l'utente a cui è concesso l'accesso alle risorse è parte del gruppo, non parte della voce LDAP propria dell'utente.

      Ad esempio, per limitare l'accesso a un gruppo, aggiungere le seguenti direttive:

      LDAPRequire group grp1

      Per questo formato di LDAPRequire, è necessario avere i gruppi configurati nel repository LDAP conformi alle seguenti regole (attraverso il nome gruppo di esempio grp1):

      • Esiste una voce nel repository LDAP che coincide con il seguente filtro di ricerca, in cui i valori groupofnames e groupofuniquenames sono di esempio e vengono indicati in ldap.group.dnattributes.
        Nota: Il giusto valore di ldap.group.dnattributes è un elenco di ciò che objectclasses vuol dire come gruppo nello schema LDAP.
        ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
        (objectclass=groupofuniquenames)))"
      • Come parte della voce LDAP per "grp1," esistono serie di attributi che corrispondono a quanto segue, dove i valori member e uniquemember sono di esempio in ldap.group.memberAttributes.
        Nota: Il valore corretto di ldap.group.memberAttributes è un elenco di ciò che objectclasses significa come membro di un gruppo. I valori di queste voci sono i DN (Distinguished Names) degli utenti.
        ldapsearch ... "(&(cn=grp1)(|(objectclass=groupofnames)
        (objectclass=groupofuniquenames)))" member uniquemember 

        Esempio:

        ldapsearch -x -h myldapserver -D cn=root -w rootpw
        "(&(cn=grp1)(|(objectclass=groupofnames)(objectclass=groupofuniquenames)))" 
        member uniquemember
        dn: cn=group1,ou=myunit,o=myorg,c=US 
        member: cn=user1, ou=otherunit, o=myorg, c=US
        member: cn=user12, ou=otherunit, o=myorg, c=US 

        Se un oggetto del tipo elencato in ldap.group.dnattributes è membro del gruppo cercato, viene cercato in modo ricorsivo nello stesso modo, fino in fondo a ldap.group.search.depth

      • All'inizio IBM HTTP Server usa ldap.group.name.filter e ldap.user.cert.filter per tradurre i CN forniti ad utenti e gruppi in DN (Distinguished Names). In seguito, esso cerca di utilizzare i DN del gruppo come base per le voci il cui valore è rappresentato dai DN dell'utente.

        Esempio:

        ldapsearch ... -b "cn=grp1,ou=myunit,o=myorg,c=US" 
        "|((member=cn=user1,ou=otherunit,o=myorg,c=US) 
        (uniquemember=cn=user1,ou=otherunit,o=myorg,c=US))"
        
    • Autorizzazione basata sugli attributi di LDAP dell'utente. Utilizzare LDAP per controllare le password utente e verificare che gli utenti soddisfino una serie di attributi (l'attributo che identifica l'utente come abile all'accesso alle risorse è parte della voce LDAP dell'utente stesso).

      Esempio:

      LDAPRequire filter "(&(jobtitle=accountant)(location=newyork))"

      Per usare questa forma di LDAPRequire, IBM HTTP Server deve utilizzare ldap.user.cert.filter per trasferire i CN forniti per l'utente in un DN. IBM HTTP Server deve inoltre cercare di utilizzare DN dell'utente come base e il filtro di ricerca fornito nella direttiva LDAPRequire. Se non viene restituito nessun risultato, l'autorizzazione avrà avuto esito positivo.

      Esempio:

      ldapsearch ... -b "cn=user1,ou=otherunit,o=myorg,c=US" "(&(jobtitle=accountant)
      (location=newyork))" 

      Alcuni attributi (chiamati a volte Ruoli dinamici - Dynamic Roles) in LDAP vengono calcolati dinamicamente dal server LDAP e possono avere semantiche differenti non valide in un filtro di ricerca. Tali valori non funzionano se usati nell'esempio precedente e non possono essere utilizzati per l'autorizzazione su IBM HTTP Server.

    • Solo autenticazione: utilizzare LDAP per controllare solo le password utente.

      È possibile utilizzare la direttiva Require per la limitazione ad utenti specifici o per il mantenimento di un file di gruppo flat mediante AuthGroupFile.

  5. Modificare il file di configurazione ldap.prop. Se questo file non è disponibile, utilizzare il file ldap.prop.sample contenuto in IBM HTTP Server. In caso di dubbi sui valori corretti, rivolgersi all'amministratore del server LDAP. Aggiornare le seguenti direttive con i valori corretti per l'ambiente utilizzato:
    1. Immettere le informazioni sulla connessione del server Web.
    2. Con SSL o LDAPS o LDAP su SSL:
      • Modificare ldap.transport su un valore SSL
      • Modificare ldap.URL per includere il protocollo LDAPS ed il corretto valore di porta, ad esempio 636.
      • Configurare il database chiavi SSL da usare, ad esempio:
        ldap.key.fileName=/percorso/key.kdb
        
        ldap.key.file.password.stashFile=/path_to/stashfile
        Dove stashfile viene creato dal comando bin/ldapstash.
        ldap.key.label=label
        Dove label è il valore che appare in IKEYMAN per key.kdb a cui si fa riferimento.

Risultati

Le ricerche che utilizzano le direttive mod_ibm_ldap mantengono un pool di connessioni server che vengono autenticate così come l'utente ldap.application.dn. La prima connessione viene creata una volta ricevuta la prima richiesta protetta da LDAP. Le connessioni rimangono aperte per un determinato numero di secondi (ldap.idleConnection.timeout) per ricerche successive su quella connessione o connessioni per altre richieste.

Durante la lettura di log o l'osservazione di una traccia IP, dovrebbero verificarsi i seguenti eventi:




Argomenti secondari
LDAP (Lightweight Directory Access Protocol)
Interrogazione del server LDAP (Lightweight Directory Access Protocol)
Modulo SSL (Secure Sockets Layer) e del modulo LDAP (Lightweight Directory Access Protocol)
CRL (Certificate Revocation List) SSL
Direttive LDAP
Argomento attività    

Termini di utilizzo | Commenti

Ultimo aggiornamento: Feb 22, 2009 8:43:20 AM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_ldapconfig.html