k-space/dex
Archived
10
0
Fork 0
Code Issues Pull Requests Packages Projects Activity

Documentation: clarify difference between LDAP ports and security guarantees

Browse Source 
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.
This commit is contained in:
Eric Chiang 2016-11-23 12:26:44 -08:00
parent 5ed42be7a5
commit 8b8c076ecf
1 changed files with 21 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
Documentation/ldap-connector.md
View File

@ -9,6 +9,12 @@ The connector executes two primary queries:
1. Finding the user based on the end user's credentials. 1. Finding the user based on the end user's credentials.
2. Searching for groups using the user entry. 2. Searching for groups using the user entry.
## Security considerations
Dex attempts to bind with the backing LDAP server using the end user's _plain text password_. Though some LDAP implementations allow passing hashed passwords, dex doesn't support hashing and instead _strongly recommends that all administrators just use TLS_. This can often be achieved by using port 636 instead of 389, and administrators that choose 389 are actively leaking passwords.
Dex currently allows insecure connections because the project is still verifying that dex works with the wide variety of LDAP implementations. However, dex may remove this transport option, and _users who configure LDAP login using 389 are not covered by any compatibility guarantees with future releases._
## Configuration ## Configuration
User entries are expected to have an email attribute (configurable through `emailAttr`), and a display name attribute (configurable through `nameAttr`). `*Attr` attributes could be set to "DN" in situations where it is needed but not available elsewhere, and if "DN" attribute does not exist in the record. User entries are expected to have an email attribute (configurable through `emailAttr`), and a display name attribute (configurable through `nameAttr`). `*Attr` attributes could be set to "DN" in situations where it is needed but not available elsewhere, and if "DN" attribute does not exist in the record.
@ -16,18 +22,31 @@ User entries are expected to have an email attribute (configurable through `emai
The following is an example config file that can be used by the LDAP connector to authenticate a user. The following is an example config file that can be used by the LDAP connector to authenticate a user.
```yaml ```yaml
connectors: connectors:
- type: ldap - type: ldap
id: ldap id: ldap
config: config:
# Host and optional port of the LDAP server in the form "host:port". # Host and optional port of the LDAP server in the form "host:port".
# If the port is not supplied, it will be guessed based on the TLS config. # If the port is not supplied, it will be guessed based on "insecureNoSSL".
# 389 for insecure connections, 636 otherwise.
host: ldap.example.com:636 host: ldap.example.com:636
# Following field is required if the LDAP host is not using TLS (port 389). # Following field is required if the LDAP host is not using TLS (port 389).
# Because this option inherently leaks passwords to anyone on the same network
# as dex, THIS OPTION MAY BE REMOVED WITHOUT WARNING IN A FUTURE RELEASE.
# insecureNoSSL: true # insecureNoSSL: true
# If a custom certificate isn't provide, this option can be used to turn on
# TLS certificate checks. As noted, it is insecure and shouldn't be used outside
# of explorative phases.
# insecureSkipVerify: true
# Path to a trusted root certificate file. Default: use the host's root CA. # Path to a trusted root certificate file. Default: use the host's root CA.
rootCA: /etc/dex/ldap.ca rootCA: /etc/dex/ldap.ca
# A raw certificate file can also be provided inline.
# rootCAData: ( base64 encoded PEM file )
# The DN and password for an application service account. The connector uses # The DN and password for an application service account. The connector uses
# these credentials to search for users and groups. Not required if the LDAP # these credentials to search for users and groups. Not required if the LDAP
# server provides access for anonymous auth. # server provides access for anonymous auth.