The list of groups is paginated (default page is 200), so when a user
has more than 200 groups, only the first 200 are retrieve.
This change is retrieving all the groups for a user by querying all the
pages.
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>
This has added the access=offline parameter and prompt=consent parameter
to the initial request, this works with google, assuming other providers
will ignore the prompt parameter
There's been some discussion in #1065 regarding what to do about
refreshing groups. As it stands today dex doesn't update any of the
claims on refresh (groups would just be another one). The main concern
with enabling it is that group claims may change more frequently. While
we continue to wait on the upstream refresh flows, this adds an option
to enable the group claim. This is disabled by default (so no behavioral
change) but enables those that are willing to have the delay in group
claim change to use oidc IDPs.
Workaround to #1065
If you have an oidc connector configured *and* that IDP provides thin
tokens (e.g. okta) then the majority of the requested claims come in the
getUserInfo call (such as email_verified). So if getUserInfo is
configured it should be run before claims are validated.
