Hi Christopher, I'll try to answer best as I can inline:
> >> 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. >> >> >> Sounds reasonable so far. > 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. >> > It's an intriguing idea but sound tricky to do given how connectors currently work. Could you sketch out the API you have in mind? > >> I assume there are other users or potential users of dex that have some >> legacy systems like I do, and it would be easier for them to maintain a >> separate application with small HTTP API than adding or maintaining >> connectors to dex that are not necessarily useful to others. Is this >> something that anyone else has expressed interest in? >> > Maintaining a patched dex sounds easier than all this, if your patch is just limited to adding a custom connector, is my opinion. > >> For this type of a connector to be useful to me, I would still need to be >> able to then enrich the JWTs with additional claims. oidc.Identity as >> returned by Identity() today does not allow/encourage this. Is there >> another extension point (real or planned) for connectors that would allow >> me to pass along additional information? >> > I agree with the limitedness of oidc.Identity. A little background here: originally dex was an internal project and in comprised what is now dex, and what is now go-oidc in one project. When we decided to opensource it, we split it up into dex, the IdP, and go-oidc, the OIDC library. Some stuff made it into go-oidc which, in retrospect, probably is dex-specific. Identity I think is one of those things. off the top of my head: I would do something like the following: remove dex's dependency on the Identity type, and create one within dex. This might be a big change in terms of LOC, but fairly mechanical (I think). Then add something like "other claims" which could just be a Claims object. Then connectors could populate it with whatever they want. (And eventually, remove Identity from go-oidc altogether I think) > >> user.AddToClaims() is another potential extension point I found. I like >> that it would work for enriching JWTs for oauth2.GrantTypeRefreshToken >> requests too, however adding the additional claims to this function would >> require me to use LDAP credentials other than the users, as they are no >> longer available at the time of this call. Does anyone think it would be >> better to add additional claims here instead of from a connector? >> > I'm afraid you've lost me here :) What do you mean by "at the time of this call" - where exactly do you mean? In CodeToken or RefreshToken you mean? > >> Any other ideas on how best to add additional claims? >> >> >> Thanks, >> >>
