This allows users of the LDAP connector to give users of Dex' login
prompt an idea of what they should enter for a username.
Before, irregardless of how the LDAP connector was set up, the prompt
was
Username
[_________________]
Password
[_________________]
Now, this is configurable, and can be used to say "MyCorp SSO Login" if
that's what it is.
If it's not configured, it will default to "Username".
For the passwordDB connector (local users), it is set to "Email
Address", since this is what it uses.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
When connecting to an LDAP server, there are three ways to connect:
1. Insecurely through port 389 (LDAP).
2. Securely through port 696 (LDAPS).
3. Insecurely through port 389 then negotiate TLS (StartTLS).
This PR adds support for the 3rd flow, letting dex connect to the
standard LDAP port then negotiating TLS through the LDAP protocol
itself.
See a writeup here:
http://www.openldap.org/faq/data/cache/185.html
Now that LDAP supports an `insecureSkipVerify` option, clarify that
`insecureNoTLS` is an extremely bad choice and as such we may drop
support for 389 in the future.
However, since we send plain text passwords from our frontend to our
backend, this probably gets us into a bigger conversation about dex's
TLS story. For example when terminiation is approporate. cc'ing
@dghubble for thoughts on how that might apply to our internal uses.
We probably want an overaching security doc at some point, but that
can be another PR.
Specify "DN" as attribute name to return, but will only work if not present in ldap.Entry.Attributes
Use when full DN is stored in groupSearch's userAttr
