Hello Bobby,
On Tuesday, May 3, 2016 at 8:11:45 PM UTC-7, Bobby Rullo wrote:
[...]
> 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 thinking of something similar to the following.
POST /*auth*
{
id: string,
password: string
}
200 OK
{
id: string,
email: string,
name: string,
claims: {
claim1: string,
claim2: [string1, string2, ...]
}
}
401 by default
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.
>
I agree that it would be easier initially, but not in the medium to long
term. To take advantage of new dex features and capabilities, I would
prefer to bump the version number in my k8s deployment spec files over
merging the latest changes to a private branch.
>>> 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)
>
ok. I think this would work for oauth2.GrantTypeAuthCode requests, but is
not enough for oauth2.GrantTypeRefreshToken requests. For
oauth2.GrantTypeRefreshToken requests to maintain the additional claims,
they would need to be persisted along with the refresh token (to keep the
same lifecycle) or...
>>> 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?
>
>>
>>>
For an oauth2.GrantTypeRefreshToken request, any additional claims added by
the connector for the original oauth2.GrantTypeAuthCode request will be
lost unless they are either persisted to the db or if another LDAP search
is performed. user.AddToClaims() is called for both request types, so I
see it as another possible extension point for adding additional claims,
but right now my I would prefer to persist them with the refresh token.
Does that make sense?
