The groupsClaimMapping setting allows one to specify which claim to pull
group information from the OIDC provider. Previously it assumed group
information was always in the "groups" claim, but that isn't the case
for many OIDC providers (such as AWS Cognito using the "cognito:groups"
claim instead)
Signed-off-by: Scott Lemmon <slemmon@aurora.tech>
Signed-off-by: Rui Yang <ruiya@vmware.com>
This should make AllowedGroups equivalent to an LDAP group filter:
When set to true, only the groups from AllowedGroups will be included in the
user's identity.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
* Add atlassiancrowd connector to list in readme
* Add TestIdentityFromCrowdUser
* Set preferred_username claim when configured
* Add preferredUsernameField option to docs
* Log warning when mapping invalid crowd field
* Added Email of Keystone to Identity
After the successful login to keystone, the Email of the logged in user
is fetch from keystone and provided to `identity.Email`.
This is useful for upstream software that uses the Email as the primary
identification.
* Removed unnecessary code from getUsers
* Changed creation of userResponse in keystone
* Fixing linter error
Co-authored-by: Christoph Glaubitz <christoph.glaubitz@innovo-cloud.de>
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.
Some oauth providers return "thin tokens" which won't include all of the
claims requested. This simply adds an option which will make the oidc
connector use the userinfo endpoint to fetch all the claims.
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>
For downstream apps using a github handle is much simpler than working
with numbers.
WHilst the number is stable and the handle is not - GitHUb does give you
a big scary wanring if you try and change it that bad things may happen
to you, and generally few users ever change it.
This can be enabled with a configuration option `useLoginAsId`
