mystiq/dex
Archived
4
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity
This repository has been archived on 2022-08-17. You can view files and clone it, but cannot push or open issues or pull requests.
dex/connector/ldap/ldap_test.go

1084 lines
24 KiB
Go
Raw Normal View History

connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
package ldap
import (
"context"
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
"fmt"
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
"io/ioutil"
"os"
"path/filepath"
"testing"
"time"
"github.com/kylelemons/godebug/pretty"
: update {S->s}irupsen/logrus
2017-07-26 02:15:17 +05:30
"github.com/sirupsen/logrus"
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
"github.com/testcontainers/testcontainers-go"
"github.com/testcontainers/testcontainers-go/wait"
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
*: github.com/coreos/dex -> github.com/dexidp/dex Signed-off-by: Stephan Renatus <srenatus@chef.io>
2018-09-03 12:14:44 +05:30
"github.com/dexidp/dex/connector"
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
)
const envVar = "DEX_LDAP_TESTS"
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
// connectionMethod indicates how the test should connect to the LDAP server.
type connectionMethod int32
const (
connectStartTLS connectionMethod = iota
connectLDAPS
connectLDAP
connector/ldap: add test for InsecureSkipVerify option
2017-10-10 02:57:22 +05:30
connectInsecureSkipVerify
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
)
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
// subtest is a login test against a given schema.
type subtest struct {
// Name of the sub-test.
name string
// Password credentials, and if the connector should request
// groups as well.
username string
password string
groups bool
// Expected result of the login.
wantErr bool
wantBadPW bool
want connector.Identity
}
func TestQuery(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
objectClass: inetOrgPerson
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
objectClass: inetOrgPerson
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
},
},
{
name: "invalidpassword",
username: "jane",
password: "badpassword",
wantBadPW: true,
},
{
name: "invaliduser",
username: "idontexist",
password: "foo",
wantBadPW: true, // Want invalid password, not a query error.
},
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
runTests(t, schema, connectLDAP, c, tests)
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
}
LDAP connector - add emailSuffix config option
2019-01-09 08:31:42 +05:30
func TestQueryWithEmailSuffix(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
userpassword: bar
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailSuffix = "test.example.com"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
tests := []subtest{
{
name: "ignoremailattr",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "jane@test.example.com",
EmailVerified: true,
},
},
{
name: "nomailattr",
username: "john",
password: "bar",
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "john@test.example.com",
EmailVerified: true,
},
},
}
runTests(t, schema, connectLDAP, c, tests)
}
ldap_test: add filter tests 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>
2018-06-14 13:40:15 +05:30
func TestUserFilter(t *testing.T) {
schema := `
dn: ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Seattle
dn: ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Portland
dn: ou=People,ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: ou=People,ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,ou=Seattle,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=jane,ou=People,ou=Portland,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoefromportland@example.com
userpassword: baz
dn: cn=john,ou=People,ou=Seattle,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
`
c := &Config{}
c.UserSearch.BaseDN = "dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.UserSearch.Filter = "(ou:dn:=Seattle)"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,ou=Seattle,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
want: connector.Identity{
UserID: "cn=john,ou=People,ou=Seattle,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
},
},
{
name: "invalidpassword",
username: "jane",
password: "badpassword",
wantBadPW: true,
},
{
name: "invaliduser",
username: "idontexist",
password: "foo",
wantBadPW: true, // Want invalid password, not a query error.
},
}
runTests(t, schema, connectLDAP, c, tests)
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
func TestGroupQuery(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
objectClass: inetOrgPerson
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
objectClass: inetOrgPerson
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
# Group definitions.
dn: ou=Groups,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: cn=admins,ou=Groups,dc=example,dc=org
objectClass: groupOfNames
cn: admins
member: cn=john,ou=People,dc=example,dc=org
member: cn=jane,ou=People,dc=example,dc=org
dn: cn=developers,ou=Groups,dc=example,dc=org
objectClass: groupOfNames
cn: developers
member: cn=jane,ou=People,dc=example,dc=org
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.GroupSearch.BaseDN = "ou=Groups,dc=example,dc=org"
connector/ldap: add multiple user to group mapping 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>
2020-01-03 15:10:08 +05:30
c.GroupSearch.UserMatchers = []UserMatcher{
{
UserAttr: "DN",
GroupAttr: "member",
},
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
c.GroupSearch.NameAttr = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
groups: true,
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "developers"},
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
groups: true,
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
Groups: []string{"admins"},
},
},
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
runTests(t, schema, connectLDAP, c, tests)
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
}
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
func TestGroupsOnUserEntity(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
# Groups are enumerated as part of the user entity instead of the members being
# a list on the group entity.
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
departmentNumber: 1000
departmentNumber: 1001
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
departmentNumber: 1000
departmentNumber: 1002
# Group definitions. Notice that they don't have any "member" field.
dn: ou=Groups,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: cn=admins,ou=Groups,dc=example,dc=org
objectClass: posixGroup
cn: admins
gidNumber: 1000
dn: cn=developers,ou=Groups,dc=example,dc=org
objectClass: posixGroup
cn: developers
gidNumber: 1001
dn: cn=designers,ou=Groups,dc=example,dc=org
objectClass: posixGroup
cn: designers
gidNumber: 1002
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.GroupSearch.BaseDN = "ou=Groups,dc=example,dc=org"
connector/ldap: add multiple user to group mapping 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>
2020-01-03 15:10:08 +05:30
c.GroupSearch.UserMatchers = []UserMatcher{
{
UserAttr: "departmentNumber",
GroupAttr: "gidNumber",
},
}
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
c.GroupSearch.NameAttr = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
groups: true,
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "developers"},
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
groups: true,
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "designers"},
},
},
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
runTests(t, schema, connectLDAP, c, tests)
}
ldap_test: add filter tests 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>
2018-06-14 13:40:15 +05:30
func TestGroupFilter(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
# Group definitions.
dn: ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Seattle
dn: ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Portland
dn: ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: ou=Groups,ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
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=admins,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: admins
member: cn=john,ou=People,dc=example,dc=org
member: cn=jane,ou=People,dc=example,dc=org
dn: cn=developers,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: developers
member: cn=jane,ou=People,dc=example,dc=org
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.GroupSearch.BaseDN = "dc=example,dc=org"
connector/ldap: add multiple user to group mapping 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>
2020-01-03 15:10:08 +05:30
c.GroupSearch.UserMatchers = []UserMatcher{
{
UserAttr: "DN",
GroupAttr: "member",
},
}
ldap_test: add filter tests 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>
2018-06-14 13:40:15 +05:30
c.GroupSearch.NameAttr = "cn"
c.GroupSearch.Filter = "(ou:dn:=Seattle)" // ignore other groups
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
groups: true,
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "developers"},
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
groups: true,
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
Groups: []string{"admins"},
},
},
}
connector/ldap: add multiple user to group mapping 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>
2020-01-03 15:10:08 +05:30
runTests(t, schema, connectLDAP, c, tests)
}
func TestGroupToUserMatchers(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
uid: janedoe
mail: janedoe@example.com
userpassword: foo
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
# Group definitions.
dn: ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Seattle
dn: ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Portland
dn: ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: ou=UnixGroups,ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: UnixGroups
dn: ou=Groups,ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: ou=UnixGroups,ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: UnixGroups
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
dn: cn=admins,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: admins
member: cn=john,ou=People,dc=example,dc=org
member: cn=jane,ou=People,dc=example,dc=org
dn: cn=developers,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: developers
member: cn=jane,ou=People,dc=example,dc=org
dn: cn=frontend,ou=UnixGroups,ou=Seattle,dc=example,dc=org
objectClass: posixGroup
gidNumber: 1001
cn: frontend
memberUid: janedoe
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.GroupSearch.BaseDN = "dc=example,dc=org"
c.GroupSearch.UserMatchers = []UserMatcher{
{
UserAttr: "DN",
GroupAttr: "member",
},
{
UserAttr: "uid",
GroupAttr: "memberUid",
},
}
c.GroupSearch.NameAttr = "cn"
c.GroupSearch.Filter = "(|(objectClass=posixGroup)(objectClass=groupOfNames))" // search all group types
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
groups: true,
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "developers", "frontend"},
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
groups: true,
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
Groups: []string{"qa", "admins", "logger"},
},
},
}
connector/ldap: backward compatibility with single user to group mapping Signed-off-by: Vitaliy Dmitriev <vi7alya@gmail.com>
2020-01-07 19:25:13 +05:30
runTests(t, schema, connectLDAP, c, tests)
}
// Test deprecated group to user matching implementation
// which was left for backward compatibility.
// See "Config.GroupSearch.UserMatchers" comments for the details
func TestDeprecatedGroupToUserMatcher(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
dn: cn=john,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
mail: johndoe@example.com
userpassword: bar
# Group definitions.
dn: ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Seattle
dn: ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Portland
dn: ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
dn: ou=Groups,ou=Portland,dc=example,dc=org
objectClass: organizationalUnit
ou: Groups
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=admins,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: admins
member: cn=john,ou=People,dc=example,dc=org
member: cn=jane,ou=People,dc=example,dc=org
dn: cn=developers,ou=Groups,ou=Seattle,dc=example,dc=org
objectClass: groupOfNames
cn: developers
member: cn=jane,ou=People,dc=example,dc=org
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
c.GroupSearch.BaseDN = "dc=example,dc=org"
c.GroupSearch.UserAttr = "DN"
c.GroupSearch.GroupAttr = "member"
c.GroupSearch.NameAttr = "cn"
c.GroupSearch.Filter = "(ou:dn:=Seattle)" // ignore other groups
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
groups: true,
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
Groups: []string{"admins", "developers"},
},
},
{
name: "validpassword2",
username: "john",
password: "bar",
groups: true,
want: connector.Identity{
UserID: "cn=john,ou=People,dc=example,dc=org",
Username: "john",
Email: "johndoe@example.com",
EmailVerified: true,
Groups: []string{"admins"},
},
},
}
ldap_test: add filter tests 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>
2018-06-14 13:40:15 +05:30
runTests(t, schema, connectLDAP, c, tests)
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
func TestStartTLS(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
},
},
}
runTests(t, schema, connectStartTLS, c, tests)
}
connector/ldap: add test for InsecureSkipVerify option
2017-10-10 02:57:22 +05:30
func TestInsecureSkipVerify(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
},
},
}
runTests(t, schema, connectInsecureSkipVerify, c, tests)
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
func TestLDAPS(t *testing.T) {
schema := `
dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
ou: People
dn: cn=jane,ou=People,dc=example,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
mail: janedoe@example.com
userpassword: foo
`
c := &Config{}
c.UserSearch.BaseDN = "ou=People,dc=example,dc=org"
c.UserSearch.NameAttr = "cn"
c.UserSearch.EmailAttr = "mail"
c.UserSearch.IDAttr = "DN"
c.UserSearch.Username = "cn"
tests := []subtest{
{
name: "validpassword",
username: "jane",
password: "foo",
want: connector.Identity{
UserID: "cn=jane,ou=People,dc=example,dc=org",
Username: "jane",
Email: "janedoe@example.com",
EmailVerified: true,
},
},
}
runTests(t, schema, connectLDAPS, c, tests)
connector/ldap: fix case where groups are listed on the user entity 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
2017-04-11 22:18:48 +05:30
}
password connectors: allow overriding the username attribute (password prompt) 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>
2017-11-07 14:58:21 +05:30
func TestUsernamePrompt(t *testing.T) {
tests := map[string]struct {
config Config
expected string
}{
"with usernamePrompt unset it returns \"\"": {
config: Config{},
expected: "",
},
"with usernamePrompt set it returns that": {
config: Config{UsernamePrompt: "Email address"},
expected: "Email address",
},
}
for n, d := range tests {
t.Run(n, func(t *testing.T) {
conn := &ldapConnector{Config: d.config}
if actual := conn.Prompt(); actual != d.expected {
t.Errorf("expected %v, got %v", d.expected, actual)
}
})
}
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
// runTests runs a set of tests against an LDAP schema. It does this by
// setting up an OpenLDAP server and injecting the provided scheme.
//
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
// The tests require Docker.
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
//
// The DEX_LDAP_TESTS must be set to "1"
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
func runTests(t *testing.T, schema string, connMethod connectionMethod, config *Config, tests []subtest) {
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
if os.Getenv(envVar) != "1" {
t.Skipf("%s not set. Skipping test (run 'export %s=1' to run tests)", envVar, envVar)
}
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
wd, err := os.Getwd()
if err != nil {
t.Fatal(err)
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
tempDir, err := ioutil.TempDir("", "")
if err != nil {
t.Fatal(err)
}
defer os.RemoveAll(tempDir)
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
schemaPath := filepath.Join(tempDir, "schema.ldif")
if err := ioutil.WriteFile(schemaPath, []byte(schema), 0777); err != nil {
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
t.Fatal(err)
}
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
req := testcontainers.ContainerRequest{
Image: "osixia/openldap:1.3.0",
ExposedPorts: []string{"389/tcp", "636/tcp"},
Cmd: []string{"--copy-service"},
Env: map[string]string{
"LDAP_BASE_DN": "dc=example,dc=org",
"LDAP_TLS": "true",
"LDAP_TLS_VERIFY_CLIENT": "try",
},
BindMounts: map[string]string{
filepath.Join(wd, "testdata", "certs"): "/container/service/slapd/assets/certs",
schemaPath: "/container/service/slapd/assets/config/bootstrap/ldif/99-schema.ldif",
},
WaitingFor: wait.ForAll(
wait.ForLog("slapd starting").WithOccurrence(3).WithStartupTimeout(time.Minute),
wait.ForListeningPort("389/tcp"),
wait.ForListeningPort("636/tcp"),
),
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
}
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
ctx := context.Background()
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
slapd, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
ContainerRequest: req,
Started: true,
})
if err != nil {
if slapd != nil {
logs, err := slapd.Logs(ctx)
if err == nil {
defer logs.Close()
logLines, err := ioutil.ReadAll(logs)
if err != nil {
t.Log(string(logLines))
}
}
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
t.Fatal(err)
}
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
defer slapd.Terminate(ctx)
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
ip, err := slapd.Host(ctx)
if err != nil {
t.Fatal(err)
}
port, err := slapd.MappedPort(ctx, "389")
if err != nil {
t.Fatal(err)
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
}
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
tlsPort, err := slapd.MappedPort(ctx, "636")
if err != nil {
t.Fatal(err)
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
}
// Shallow copy.
c := *config
// We need to configure host parameters but don't want to overwrite user or
// group search configuration.
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
switch connMethod {
case connectStartTLS:
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
c.Host = fmt.Sprintf("%s:%s", ip, port.Port())
c.RootCA = "testdata/certs/ca.crt"
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
c.StartTLS = true
case connectLDAPS:
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
c.Host = fmt.Sprintf("%s:%s", ip, tlsPort.Port())
c.RootCA = "testdata/certs/ca.crt"
connector/ldap: add test for InsecureSkipVerify option
2017-10-10 02:57:22 +05:30
case connectInsecureSkipVerify:
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
c.Host = fmt.Sprintf("%s:%s", ip, tlsPort.Port())
connector/ldap: add test for InsecureSkipVerify option
2017-10-10 02:57:22 +05:30
c.InsecureSkipVerify = true
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
case connectLDAP:
Rewrite LDAP tests to use Docker
2019-12-09 00:51:28 +05:30
c.Host = fmt.Sprintf("%s:%s", ip, port.Port())
connector/ldap: support the StartTLS flow for secure connections 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
2017-04-13 02:43:34 +05:30
c.InsecureNoSSL = true
}
connector/ldap: add LDAP integration tests
2017-04-11 03:32:40 +05:30
c.BindDN = "cn=admin,dc=example,dc=org"
c.BindPW = "admin"
l := &logrus.Logger{Out: ioutil.Discard, Formatter: &logrus.TextFormatter{}}
conn, err := c.openConnector(l)
if err != nil {
t.Errorf("open connector: %v", err)
}
for _, test := range tests {
if test.name == "" {
t.Fatal("go a subtest with no name")
}
// Run the subtest.
t.Run(test.name, func(t *testing.T) {
s := connector.Scopes{OfflineAccess: true, Groups: test.groups}
ident, validPW, err := conn.Login(context.Background(), s, test.username, test.password)
if err != nil {
if !test.wantErr {
t.Fatalf("query failed: %v", err)
}
return
}
if test.wantErr {
t.Fatalf("wanted query to fail")
}
if !validPW {
if !test.wantBadPW {
t.Fatalf("invalid password: %v", err)
}
return
}
if test.wantBadPW {
t.Fatalf("wanted invalid password")
}
got := ident
got.ConnectorData = nil
if diff := pretty.Compare(test.want, got); diff != "" {
t.Error(diff)
return
}
// Verify that refresh tokens work.
ident, err = conn.Refresh(context.Background(), s, ident)
if err != nil {
t.Errorf("refresh failed: %v", err)
}
got = ident
got.ConnectorData = nil
if diff := pretty.Compare(test.want, got); diff != "" {
t.Errorf("after refresh: %s", diff)
}
})
}
}
Reference in a new issue Copy permalink