Hello,
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.
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.
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?
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?
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?
Any other ideas on how best to add additional claims?
Thanks,
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.
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.
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?
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?
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?
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?
POST /auth
{
id: string,
password: string
}
200 OK
{
id: string,
email: string,
name: string,
claims: {
claim1: string,
claim2: [string1, string2, ...]
}
}
My expectation is the 'local_http' connector would only allow the port and a timeout to be configured and not the hostname to prevent/discourage users from making requests over the network.
dex could then be extended by others without the need to patch dex using a simple adapter application that implements the '/auth' endpoint. The adapter application could be written in any language too, enabling easier integration by groups with legacy libraries not written in Go.
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?
> 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.
> 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.
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.