LDAP_BIND / UNBIND

Sinossi

Parametri di input

ld

Specifica il puntatore LDAP restituito da una chiamata precedente a ldap_init(), ldap_ssl_init() o ldap_open().

dn

Specifica il Distinguished Nomi (DN) della voce da legare come.

mechanism

Sebbene vari meccanismi siano IANA (Internet Assegnate Numeri Authority) registrati, gli unici meccanismi di base supportati dalla libreria LDAP attualmente sono:

• Meccanismo LDAP_MECHANISM_EXTERNAL , rappresentato dalla stringa EXTERNAL.
• Meccanismo LDAP_MECHANISM_GSSAPI , rappresentato dalla stringa GSSAPI.
• Meccanismo LDAP_MECHANISM_DIGEST_MD5 , rappresentato dalla stringa DIGEST-MD5.
  Nota: Il meccanismo CRAM-MD5 non è supportato in un'operazione di collegamento.

Il meccanismo LDAP_MECHANISM_EXTERNAL indica al server che le informazioni esterne a SASL devono essere utilizzate per stabilire se il client è autorizzato all'autenticazione. Per questa implementazione il sistema che fornisce le informazioni esterne deve essere SSL. Ad esempio, se il client imposta il DN e le credenziali su NULL (il valore dei puntatori deve essere NULL), con il meccanismo impostato su LDAP_MECHANISM_EXTERNAL, il client richiede che il server utilizzi l'identità autenticata dal certificato X.509 del client utilizzato per autenticare il client sul server durante l'handshake SSL. Il server può quindi utilizzare l'identità autenticata per accedere alla directory.

Il meccanismo LDAP_MECHANISM_GSSAPI viene utilizzato per abilitare l'autenticazione Kerberos . Nell'autenticazione Kerberos , un client presenta credenziali valide ottenute da un KDC (key distribution center) Kerberos a un server delle applicazioni. Il server decodifica e verifica le credenziali utilizzando il relativo tasto di servizio.

Quando mechanism è impostato su un puntatore NULL, la richiesta di collegamento SASL viene interpretata come una richiesta di autenticazione semplice, vale a dire, equivalente all'utilizzo di ldap_simple_bind() o ldap_simple_bind_s().

Per ulteriori informazioni sull'utilizzo dei plug-in del client LDAP, consultare LDAP_PLUGIN_REGISTRATION. Per ulteriori informazioni sullo sviluppo di un plug-in del client LDAP, consultare Riferimento alla programmazione del plug-in del client LDAP.

Il meccanismo LDAP_MECHANISM_DIGEST_MD5 viene utilizzato per autenticare l'ID e la parola d'ordine con il server utilizzando un protocollo di verifica o di risposta. Il protocollo protegge la password di testo chiaro sul filo e impedisce gli attacchi di riproduzione.

Questo meccanismo è utile solo quando il server LDAP può richiamare la password dell'utente. Se la password è memorizzata in un formato con hash, ad esempio, crypt o SHA, l'autenticazione utilizzando il meccanismo DIGEST-MD5 non riesce. Quando si utilizza il meccanismo DIGEST-MD5 , il nome host fornito nella chiamata ldap_init deve essere risolto nel nome host completo del server.

L'applicazione deve fornire un nome utente sulla chiamata ldap_sasl_bind_s utilizzando il controllo client IBM_CLIENT_MD5_USER_NAME_OID . L'applicazione può fornire facoltativamente un realm sulla chiamata ldap_sasl_bind_s utilizzando il controllo client IBM_CLIENT_MD5_REALM_NAME_OID . L'applicazione può fornire facoltativamente un ID autorizzazione come parametro dn .

cred

Specifica le credenziali con cui autenticarsi. Le credenziali arbitrarie possono essere passate con questo parametro. Nella maggior parte dei casi, questa credenziale è la password utente. Quando si utilizza un bind SASL (Simple Authentication Security Layer), il formato e il contenuto delle credenziali dipende dall'impostazione del parametro meccanismo.

method

Seleziona il metodo di autenticazione da utilizzare. Specificare LDAP_AUTH_SIMPLE per l'autenticazione semplice o LDAP_AUTH_SASL per il collegamento SASL. L'utilizzo delle API ldap_bind e ldap_bind_s è obsoleto.

password

Specifica la password che viene utilizzata in associazione con il DN della voce in cui legarsi.

serverctrls

Specifica un elenco di controlli server LDAP. Per ulteriori informazioni sui controlli del server, consultare Controlli LDAP.

clientctrls

Specifica un elenco di controlli client LDAP. Per ulteriori informazioni sui controlli client, consultare Controlli LDAP.

rebindproc

Specifica il punto di ingresso di una routine chiamata per ottenere credenziali di collegamento che vengono utilizzate quando un nuovo server viene contattato a seguito di un rinvio LDAP.

Parametri di output

msgidp

Questo parametro di risultato è impostato sull'ID del messaggio della richiesta se la chiamata ldap_sasl_bind() ha esito positivo.

servercredp

Questo parametro risultato è impostato sulle credenziali restituite dal server. Se non vengono restituite credenziali, è impostata su NULL.

Utilizzo

Queste routine forniscono varie interfacce all'operazione di bind LDAP. Dopo aver utilizzato ldap_init, ldap_ssl_init o ldap_open per creare un handle LDAP, è possibile eseguire un bind prima che vengano tentate altre operazioni sulla connessione. Sono fornite sia le versioni sincrone che asincrona di ogni variante della chiamata di collegamento.

Un binding è facoltativo quando si comunica con un server LDAP che supporta il protocollo LDAP V3 . L'assenza di un bind viene interpretata dal server LDAP V3 come richiesta di accesso non autenticato. Un binding è richiesto dai server LDAP che supportano solo il protocollo LDAP V2 .

Le API ldap_simple_bind() e ldap_simple_bind_s() forniscono un'autenticazione semplice, utilizzando un ID utente o dn e una password che viene passata in testo chiaro all'API LDAP.

ldap_bind() e ldap_bind_s() forniscono routine di autenticazione generali, dove è possibile scegliere un metodo di autenticazione. In questo toolkit, method deve essere impostato su LDAP_AUTH_SIMPLE. Poiché l'utilizzo di queste due API è obsoleto, è necessario utilizzare ldap_simple_bind e ldap_simple_bind_s .

Le API ldap_sasl_bind e ldap_sasl_bind_s possono essere utilizzate per eseguire l'autenticazione generale ed estensibile su LDAP utilizzando SASL.

Tutte le routine di bind prendono ld come primo parametro come restituito da ldap_init, ldap_ssl_inito ldap_open.

Autenticazione semplice

Il formato più semplice della chiamata bind è ldap_simple_bind_s(). Richiede il DN per eseguire il bind e la parola d'ordine utente (fornita nella parola d'ordine). Restituisce un'indicazione di errore LDAP (vedere LDAP_ERROR). La chiamata ldap_simple_bind() è asincrona, prendendo gli stessi parametri ma inizializzando solo l'operazione di bind e restituendo l'ID messaggio della richiesta inviata. Il risultato dell'operazione può essere ottenuto con una chiamata successiva a ldap_result().

Autenticazione generale

Le routine ldap_bind() e ldap_bind_s() sono obsolete.

Le API obsolete possono essere utilizzate quando il metodo di autenticazione viene selezionato in fase di esecuzione. Entrambi assumono un parametro di metodo extra quando si seleziona il metodo di autenticazione da utilizzare. Tuttavia, quando si utilizza questo toolkit, method deve essere impostato su LDAP_AUTH_SIMPLE per selezionare l'autenticazione semplice. ldap_bind() e ldap_simple_bind() restituiscono l'ID messaggio della richiesta avviata. ldap_bind_s() e ldap_simple_bind_s() restituiscono un'indicazione di errore LDAP in caso di completamento non riuscito oppureLDAP_SUCCESSal completamento di successo.

Autenticazione SASL

Sono supportate cinque categorie di autenticazione SASL:

• Autenticazione SASL utilizzando il meccanismo EXTERNAL
• Autenticazione SASL utilizzando il meccanismo GSSAPI (Kerberos è supportato e implementato come plug - in)
• Autenticazione SASL utilizzando il meccanismo DIGEST-MD5 (implementato come plug - in)
• Autenticazione SASL utilizzando una libreria plug-in SASL fornita dall'utente
• Autenticazione SASL utilizzando un meccanismo SASL implementato dall'applicazione stessa

Quando il parametro di input mechanism è impostato su un puntatore NULL, la richiesta di bind SASL viene interpretata come una richiesta per l'autenticazione semplice, ovvero, equivalente all'utilizzo di ldap_simple_bind() o ldap_simple_bind_s().

Inoltre, il meccanismo di autenticazione SASL fornisce una struttura per il server LDAP per restituire le credenziali del server al client. Un'applicazione può ottenere le credenziali del server restituite dal server nel risultato del collegamento SASL con l'API ldap_parse_sasl_bind_result() .

SASL ESTERNI lega

Il motivo principale per l'utilizzo del meccanismo di collegamento EXTERNAL SASL è quello di utilizzare il meccanismo di autenticazione del client. Questo meccanismo viene fornito da SSL per autenticarsi fortemente sul server delle directory utilizzando il certificato X.509 client. Ad esempio, l'applicazione client può utilizzare la seguente logica:

• ldap_ssl_client_init (inizializza la libreria SSL)
• ldap_ssl_init (host, porta, nome), in cui il nome fa riferimento a una coppia di chiavi pubblica o privata nel file di database delle chiavi del client
• ldap_sasl_bind_s (ld, dn=NULL, mechanism=LDAP_MECHANISM_EXTERNAL, cred=NULL)

Un server che supporta questo meccanismo, come il server di Directory IBM® , può quindi accedere alla directory. Utilizza l'identità client autenticata come estratto dal certificato X.509 client.

GSSAPI SASL si lega

L'autenticazione Kerberos è supportata in questa release. Se i parametri di input per ldap_sasl_bind o ldap_sasl_bind_s sono mechanism==GSSAPI e cred==NULL, si presume che l'utente sia già autenticato su un server di sicurezza Kerberos e abbia ottenuto un TGT (ticket-granting ticket), tramite un processo di accesso desktop o utilizzando un programma come kinit. L'handle delle credenziali GSSAPI utilizzato per avviare un contesto di sicurezza sul lato client LDAP è ottenuto dal contesto di collegamento corrente. Se i parametri di input per queste due funzioni di collegamento SASL sono mechanism==GSSAPI e cred!=NULL, il chiamante delle funzioni deve fornire l'handle delle credenziali GSSAPI per il client LDAP per avviare un contesto di sicurezza con un server LDAP. Ad esempio, un server LDAP richiama una funzione di collegamento SASL con una gestione delle credenziali che il server riceve da un client come maniglia delegata delegata.

DIGEST-MD5 SASL si lega

Il server accetta le richieste di bind SASL utilizzando il meccanismo DIGEST-MD5 . Ci sono due tipi di DIGEST-MD5 richieste di bind: Richieste di bind di autenticazione iniziale e richieste di bind di Autenticazione Successiva. L'autenticazione iniziale è obbligatoria e supportata da IBM Security Directory Server. Il supporto di autenticazione successivo è facoltativo, e non è supportato da IBM Security Directory Server.

Il server risponde ad una richiesta di collegamento DIGEST-MD5 SASL con una sfida digest. La verifica contiene i valori richiesti dalla sezione RFC2831 2.1.1, con il seguente comportamento specifico dell'implementazione:

• realm - Il server invia sempre il realm in cui è configurato il server.
• nonce - Il server genera un nonce casuale.
• qop-options - Il server supporta solo auth .

La risposta successiva dal client al server deve essere un altro messaggio di collegamento DIGEST-MD5 SASL. La risposta include diversi campi con valori che il server utilizza come segue:

• username- Il server utilizza il valore del nome utente per stabilire se l'utente è collegato come amministratore o per trovare una voce nel rdbmprimario. Se il nome utente è un amministratore DigestUsername, il server utilizza tale amministratore per il collegamento. Se il nome utente non era un amministratore, il server ricerca nel rdbm primario un utente con tale nome utente. Se il nome utente non corrisponde a una singola voce o la voce non ha un valore password utente, il server restituisce LDAP_INVALID_CREDENTIALS. Stampa anche il messaggio di errore appropriato.
• realm - Il valore nel campo realm deve corrispondere al realm in cui è configurato il server. Se il valore del realm non corrisponde al realm in cui è configurato il server, il server restituisce LDAP_PROTOCOL_ERROR.
• nonce - Il valore nel campo nonce deve corrispondere al valore nonce che il server ha inviato al client con la richiesta digest. Se il valore non corrisponde, il server restituisce LDAP_PROTOCOL_ERROR.
• response - Il valore nel campo di risposta contiene un hash della password. Per ciascuno dei valori user - password che il server ottiene dalla voce utente, genera l'hash DIGEST-MD5 . Il server lo confronta quindi con l'hash dal client. Se uno corrisponde, il server restituisce LDAP_SUCCESS e l'utente è collegato come tale utente. Altrimenti, il server restituisce LDAP_INVALID_CREDENTIALS e stampa un messaggio di errore.
• authzid - Il valore nel campo authzid contiene un ID autorizzazione "dn:"- o "u:"-style da RFC 2829. Il server utilizza RFC 2829 per il controllo delle autorizzazioni dopo il bind, piuttosto che la voce trovata per il nome utente, simile all'autenticazione Proxied. La voce che il nome utente corrisponde deve avere l'autorità per utilizzare l'altro DN. Il server associa il valore a una voce simile al parametro del nome utente se authzid contiene un ID autorizzazione "u:"-style . Se l'associazione ha esito negativo, il server restituisce LDAP_INVALID_CREDENTIALS.

Plugin SASL forniti dall'utente

Lo sviluppatore dell'applicazione, o una terza parte, può implementare più meccanismi SASL utilizzando la funzione plug-in IBM Security Directory Server C-Client SASL. Ad esempio, è possibile sviluppare un plugin SASL client e server che supporta un nuovo meccanismo di autenticazione che si basa su una scansione retinica. Se il meccanismo associato a questo nuovo meccanismo di autenticazione è retscan, l'applicazione richiama ldap_sasl_bind() con il meccanismo impostato su retscan. A seconda di come sono progettati il meccanismo e il plug-in, l'applicazione potrebbe essere richiesta anche per fornire il DN e le credenziali dell'utente. In alternativa, il plugin stesso potrebbe essere responsabile dell'ottenimento dell'identità e delle credenziali dell'utente, che derivano in qualche modo da un'immagine di scansione retinica.

Se il plug-in di scansione retinica non è definito in ibmldap.conf, l'applicazione deve registrare esplicitamente il plug - in, utilizzando ldap_register_plugin () API. Per informazioni sulla definizione di un plug-in SASL da utilizzare con un'applicazione, consultare Definizione di un plug-in SASL in LDAP_BIND / UNBIND. Per ulteriori informazioni sull'utilizzo di un plug-in del client LDAP, consultare LDAP_PLUGIN_REGISTRATION. Per ulteriori informazioni sullo sviluppo di un plug-in del client LDAP, consultare Riferimento alla programmazione del plug-in del client LDAP.

tentativo

Meccanismi SASL implementati dall'applicazione

In alcuni casi, il meccanismo SASL potrebbe non richiedere la presenza di un plugin o di un qualsiasi supporto speciale nella libreria LDAP. Se l'applicazione può richiamare l'API ldap_sasl_bind() o ldap_sasl_bind_s() con i parametri appropriati al meccanismo, la libreria LDAP codifica la richiesta di collegamento SASL e la invia al server. Se un plugin viene definito per il meccanismo specificato, la richiesta viene deviata al plugin. La richiesta può fare più elaborazione prima di inviare il collegamento SASL al server.

Meccanismi SASL supportati dal server LDAP

L'applicazione può eseguire una query del DSE root del server LDAP, utilizzando ldap_search() con le seguenti impostazioni:

• DN base impostato su NULL
• ambito che è impostato su base
• filtro impostato su "(objectclass=*)"

Se il server LDAP supporta uno o più meccanismi SASL, i risultati della ricerca includono uno o più valori per il tipo di attributo supportedsaslmeccanismi .

Definizione di un plugin SASL

Quando l'applicazione emette un'API di ldap_sasl_bind_s() con un meccanismo supportato da un particolare plug-in SASL, la libreria LDAP deve essere in grado di individuare la libreria condivisa del plug - in. Sono disponibili due meccanismi per la realizzazione di un plug-in client LDAP noto alla libreria LDAP:

• Il plugin per il meccanismo SASL specificato è definito nel file ibmldap.conf .
• Il plug-in viene esplicitamente registrato dall'applicazione utilizzando l'API ldap_register_plugin() .

Per ulteriori informazioni sull'individuazione di una libreria di plug - in e sulla definizione di plug-in nel file ibmldap.conf , consultare la sezione Ricerca della libreria di plug-in in LDAP_PLUGIN_REGISTRATION.

Non vincolante

ldap_unbind_ext(), ldap_unbind()e ldap_unbind_s() sono API sincrone. Inviano una richiesta di unbind al server. Poi, chiudiamo tutte le connessioni aperte che sono associate alla maniglia della sessione LDAP. In seguito, si discostano di tutte le risorse associate alla maniglia della sessione prima di un ritorno. Non è presente alcuna risposta del server a un'operazione di unbind LDAP. Tutte e tre le funzioni unbind restituiscono LDAP_SUCCESS o un altro codice di errore LDAP se la richiesta non può essere inviata al server LDAP. Dopo una chiamata a una delle funzioni di unbind, l'handle di sessione ld non è valido e non è valido per effettuare ulteriori chiamate API LDAP utilizzando ld.

Le API ldap_unbind() e ldap_unbind_s() si comportano in modo identico. L'API ldap_unbind_ext() consente di includere esplicitamente i controlli server e client. Poiché non esiste una risposta server a una richiesta unbind, non è quindi possibile ricevere una risposta ad un controllo server inviato con una richiesta unbind.

Rilegatura mentre segue i referti

La chiamata ldap_set_rebind_proc() viene utilizzata per impostare il punto di ingresso di una routine richiamata per ottenere le credenziali di bind da utilizzare quando un nuovo server viene contattato in seguito a un riferimento LDAP o a un riferimento di ricerca. Questa funzione è disponibile solo quando LDAP_OPT_REFERRALS è impostato, che è l'impostazione predefinita. Se ldap_set_rebind_proc() non viene mai richiamato o se viene richiamato con un parametro NULL rebindproc , un bind LDAP semplice non autenticato viene sempre eseguito quando si rincorrono i riferimenti. Le caratteristiche SSL delle connessioni ai server di riferimento sono conservate quando si inseguono i referenti. Inoltre, se il bind originale era un bind LDAP V3 , viene utilizzato un bind LDAP V3 per connettersi ai server di riferimento. Se il bind originale era un bind LDAP V2 , viene utilizzato un bind LDAP V2 per connettersi ad ogni server di riferimento.

rebindproc deve essere una funzione dichiarata come segue:

  int rebindproc( LDAP *ld, char **whop, char **credp,

      int *methodp, int freeit );

La libreria LDAP richiama prima rebindproc per ottenere le credenziali di bind di riferimento e il valore del parametro freeit è zero. I parametri whop, credpe methodp devono essere impostati come appropriato. Se rebindproc restituisce LDAP_SUCCESS, l'elaborazione del riferimento continua e rebindproc viene richiamato una seconda volta con freeit diverso da zero per dare all'applicazione la possibilità di liberare la memoria assegnata nella chiamata precedente.

Se altro cheLDAP_SUCCESSviene restituito dalla prima chiamata a rebindproc, l'elaborazione del riferimento viene arrestata e il codice errore viene restituito per l'operazione LDAP originale.

Errori

Ritorno delle routine asincrone-1in caso di errore. Tuttavia, nel caso della routine di bind asincrona ldap_sasl_bind(), restituisce un codice di risultato LDAP diverso da LDAP_SUCCESS se la richiesta inviata ha avuto esito negativo. Per ottenere il codice di risultato LDAP della routine di bind asincrona, ldap_sasl_bind(), utilizzare l'API ldap_result() . Per ottenere l'errore LDAP, utilizzare l'API ldap_get_errno() . Le routine sincrone restituiscono il codice di errore LDAP che risulta dall'operazione.

Vedi anche

ldap_errore, ldap_apertura