Hello Frode, [...]
> > I am planning on using dex to authenticate users with credentials stored > in LDAP. In addition to the information returned in oidc.Identity, I need > to enrich the JWT with additional claims for the users using information > that is also stored in LDAP and I would prefer to collect this information > right after the user authenticates using their LDAP credentials. > > This is something I would like to see as well. At the time of writing the > original LDAP connector code implementing this was out of scope. If someone > can point me in the direction of how to return a richer dataset to Dex at > time of call to Identity that would be most helpfull. > Bobby Rullo mentioned in a previous post that replacing oidc.Identity type with a dex specific type was a possibility. I don't think this by itself is a enough though, as the additional claims would be lost after a oauth2.GrantTypeRefreshToken request, but it would work great for oauth2.GrantTypeAuthCode requests. I plan to spend some time tomorrow looking to see if the type needs to be fully replaced or just wrapped with a dex specific type for the IdentityProvider interface. > > Since the LDAP searches and other logic I need to use to collect this > additional information are of no use to anyone else, and I don't like the > idea of maintaining a custom branch of dex (modifying the existing LDAP > connector), I was thinking about creating a new 'local-http' connector that > would allow me to run a companion application next to every dex-worker > instance that would handle all of the connector functionally over an HTTP > API on the loopback interface. In my case, this would be sidecar > Kubernetes container in a pod that also contains a (hopefully eventually > stock) dex-worker container. > > > Adding additional claims to the JWT with data from LDAP is most definitely > something other users will have use for. Could you describe your use case > and I can try to come up with a generic and configurable way to handle it > in the LDAP connector. > > My source LDAP system(s) have a history to them, which basically means there is some duplicate data and unclean data. I'm not sure a something like issue 432 <https://github.com/coreos/dex/issues/432> would quite solve it, but the need is very similar. Basically after finding the user (or users that are really one user), I need to search multiple DNs looking for groupOfNames the user is a member of, then filter that list down to only the groups needed by systems that will use OIDC for authentication.
