LDAP connection and bind logic resides in authentication function

[viharm]

Currently the connection and bind functionality resides in the authentication function. The object construction procedure (_construct) merely organises variables for the class based on those passed with the object creation request.

This implies that even if the object is created only once, each request for authentication will initiate a connection, and binding process. This may be inefficient.

Investigate the following:

1. If the object construction procedure can connect and bind with the directory service
2. Security implications of
   1. keeping a connection open
   2. keeping a bound connection open
3. If the binding operation requires authentication using the dynamic credentials (used to authenticate), then the binding logic must conditionally either in the object creation or the authentication procedure.

[viharm]

Note that the unbind function destroys the link descriptor [ref].

Best practice may be to bind again, instead of unbinding.

[viharm]

Since many connections between LDAP client and LDAP server may be unencrypted, the current direction is to keep the connections atomic. The object creation will stay as a variable organisation process.

‌

Each authentication request will be treated separately, which will connect to the LDAP server and then attempt to bind.

[viharm]

Since many connections between LDAP client and LDAP server may be unencrypted, the current direction is to keep the connections atomic. The object creation will stay as a variable organisation process.

Each authentication request will be treated separately, which will connect to the LDAP server and then attempt to bind.