* Add LDAP Key Synchronization feature
Signed-off-by: Magnus Lindvall <magnus@dnmgns.com>
* Add migration: add login source id column for public_key table
* Only update keys if needed
* Add function to only list pubkey synchronized from ldap
* Only list pub ssh keys synchronized from ldap. Do not sort strings as ExistsInSlice does it.
* Only get keys belonging to current login source id
* Set default login source id to 0
* Some minor cleanup. Add integration tests (updete dep testify)
* Correction LDAP username validation
As https://msdn.microsoft.com/en-us/library/aa366101(v=vs.85).aspx describe spaces should not be in start or at the end of username but they can be inside the username. So please check my solution for it.
* Check for zero length passwords in LDAP module.
According to https://tools.ietf.org/search/rfc4513#section-5.1.2 LDAP client should always check before bind whether a password is an empty value. There are at least one LDAP implementation which does not return error if you try to bind with DN set and empty password - AD.
* Clearing the login/email spaces at the [start/end]
* Write LDAP, SMTP, PAM, DLDAP back to all uppercase
* Fix type in unused constant name
* Other MixCased fixes
* Complete MixerCasing of template constants
* Re uppercase LTS and LDAPS suffixes
* Uppercase JSON suffix in constant names
* Proper case LoginNoType
* Prefix unexported template path constants with "tpl"
From https://godoc.org/crypto/tls#Config
ServerName is used to verify the hostname on the returned
certificates unless InsecureSkipVerify is given. It is also included
in the client's handshake to support virtual hosting unless it is
an IP address.
This is needed for certificate validation without InsecureSkipVerify.
This is feature is workaround for #2628 (JumpCloud) and some other services
that allow LDAP search only under BindDN user account, but not allow any LDAP
search query in logged user DN context.
Such approach is an alternative to minimal permissions security pattern for
BindDN user.
According to RFC 4511 4.2.1. Processing of the Bind Request "Clients may send
multiple Bind requests to change the authentication and/or security
associations or to complete a multi-stage Bind process. Authentication from
earlier binds is subsequently ignored."
Therefore we should not use 2 connections, but single one just sending two bind
requests.
Consider following LDAP search query example:
(&(objectClass=Person)(|(uid=%s)(mail=%s)))
Right now on first login attempt Gogs will use the text supplied on login form
as the newly created user name. In example query above the text matches against
both e-mail or user name. So if user puts the e-mail then the new Gogs user
name will be e-mail which may be undesired.
Using optional user name attribute setting we can explicitly say we want Gogs
user name to be certain LDAP attribute eg. `uid`, so even user will use e-mail
to login 1st time, the new account will receive correct user name.
The IsAdmin flag is set based on whether the admin filter
returned any result. The admin filter is applied with the user dn
as the search root.
In the future, we should update IsAdmin as well on each login.
Alternately, we can have a periodic sync operation.
