Fixes #14

The following enhancements and modifications implement a way to authenticate against an LDAP server.

We assume that a successful LDAP authentication means the user is allowed to access the application independent of RBAC later in the application. This initial authorization can be varied by the object filter (or the base DN). Currently there is only one keyword value pair to define such a filter to match the username (Common Name/CN) as such.

But we still need the DB! A User record is automatically created in the DB (if it does not exist) when the user first logs in, since we still need to remember some metadata. It is updated from LDAP, if the concerning attributes are configured and LDAP exposes that information. Otherwise, local data is used (name, email, role), which can be set using User Preferences dialog. This data gets overwritten as soon as the directory contains data.

So far, the identity of the user was defined by an email address, not a username. In a directory setting, that changes. However, the User model doesn't account for a username, only an email address (and a real name). I could have:

• stored the username in the email field, thus maybe changing the semantics of that field
• stored the username in the name field, thus no longer being able to store the actual name
• UPN in AD looks like an email address so I could have stored it in email and used it as the main credentail
• in other directories like eDirectory however, the username might just be contain a plain username like "jdoe"

As a consequence I've introduced a UserLDAP model, together with an AuthLDAP controller, and also a UserPreferences view, since the single form currently used via the controller no longer cuts it. There is now also a setupUserModelLDAP() trait.

Concerning roles: I'm not sure how to handle that. Currently I'm not assigning any role at all. And there doesn't seem to be anything that is not accessible in my App. In any case we give the option to retrieve the role from LDAP.

UserAdmin will not be needed much with directory authentication, except for an admin to modify attributes not provided by LDAP. In any case, username and password cannot be changed in the application. And also not in LDAP via the application. A password field doesn't even exist anymore, so we might need to update UserAdmin to account for the new User model...RoleAdmin remains viable of course. RegisterForm is also not used in this case.

The Login form got a minor update because we need to change the caption and error message depending on the authentication type.

There is still an issue with potential user enumeration during Login:

• If the user does not exist, the form field shows an error
• If the user exists but the password is wrong then there is an ErrorException

Usage example:

$app->add(new \atk4\login\AuthLDAP([
  'ldapUrl' => 'ldap://ldap.acme.company/',
  'ldapBaseDn' => 'o=acme',
  'ldapObjFilter' => ['objectClass', 'Person'],
  'ldapFullNameAttr' => 'fullname',
  'ldapEmailAttr' => 'mail',
  ]))->setModel(new \atk4\login\Model\UserLDAP($app->db));