Add an ability to fetch user's membership from
groups of a different type by specifying multiple
group attribute to user attribute value matchers
in the Dex config:
userMatchers:
- userAttr: uid
groupAttr: memberUid
- userAttr: DN
groupAttr: member
In other words the user's groups can be fetched now from
ldap structure similar to the following:
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
uid: johndoe
mail: johndoe@example.com
userpassword: bar
dn: cn=qa,ou=Groups,ou=Portland,dc=example,dc=org
objectClass: groupOfNames
cn: qa
member: cn=john,ou=People,dc=example,dc=org
dn: cn=logger,ou=UnixGroups,ou=Portland,dc=example,dc=org
objectClass: posixGroup
gidNumber: 1000
cn: logger
memberUid: johndoe
Signed-off-by: Vitaliy Dmitriev <vi7alya@gmail.com>
The filters for user and group searches hadn't been included in our LDAP
tests. Now they are.
The concrete test cases are somewhat contrived, but that shouldn't
matter too much. Also note that the example queries I've used are not
supported in AD: https://stackoverflow.com/a/10043452
Signed-off-by: Stephan Renatus <srenatus@chef.io>
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
Support schemas that determine membership by having fields on the
user entity, instead of listing users on a groups entity. E.g. the
following schema is now supported when it wasn't previously:
cn=eric,cn=user,dn=exapmle,dn=com
objectClass=myPerson
cn: eric
uid: eric
email: eric@example.com
memberOf: foo
memberOf: bar
cn=foo,cn=group,dn=exapmle,dn=com
objectClass=myGroup
cn: foo
cn=bar,cn=group,dn=exapmle,dn=com
objectClass=myGroup
cn: bar
