OAuth fails when browser/charm/gitlab are on different hosts

[pedroleaoc]

The Legend bundle and the GitLab instance need to be in the same computer or the authentication process fails. This means gitlab.com and EKS deployments will always fail.

[claudiubelu]

When configuring the Legend Juju GitLab Integrator Charm, we have the option to provide it an already existing gitlab.com Application by providing it the bypass-client-id and bypass-client-secret config options.

Howver, when trying to start using the Legend Studio, you will be redirected to gitlab.com to log in and authorize the Legend Studio application, and after that, you're redirected to the original Legend Studio you were trying to access. Basically, the gitlab.com URL used looks something like this:

https://gitlab.com/oauth/authorize?client_id=some_client_id&redirect_uri=http%3A%2F%2F127.0.0.1%3A8080%2Fstudio%2Flog.in%2Fcallback%3Fclient_name%3Dgitlab&response_type=code&scope=openid+profile+api&state=some_state

As you can see in the URL above, there's a redirect_uri, which is basically the original Legend Studio URL you were trying to access.

Now, how the gitlab.com Application authorization works: in the gitlab.com Application, you have configured a list of Redirect URIs, which is used to ensure that no other invalid / unauthorized URL can be used for this gitlab.com Application authentication. The Redirect URLs could looks something like this:

http://10.1.243.217:6060/api/callback
http://10.1.243.214:7070/api/auth/callback
http://10.1.243.214:7070/api/pac4j/login/callback
http://10.1.243.209:8080/studio/log.in/callback

In the case above, the IPs are local to the Kubernetes cluster, which means that we can't use the Legend Studio's Public IP to authenticate it in gitlab.com, since it isn't in the list of the redirect URL mentioned above. The list above would have to be modified to include the Legend Studio Public IP endpoint, but it's also possible for that Public IP to change in the future, In that case, the Redirect URLs should be updated as well.

Ideally, those Redirect URLs would get updated automatically by the Legend Juju GitLab Integrator Charm, but another issue prevents us from doing so (#25).

[claudiubelu]

We've solved this issue by using the nginx ingress integrator charms and using the Kubernetes Service names instead of IPs. Additionally, the Legend Studio, SDLC, and Engine charms can be configured with custom DNS names as well. With the changes below, we won't have to update the Callback URLs every time the Pod IPs get updated due to various reasons.

Related:

finos/legend-juju-libs#5
finos/legend-juju-libs#8
finos/legend-juju-libs#9
finos/legend-juju-studio-operator#7
finos/legend-juju-sdlc-server-operator#9
finos/legend-juju-engine-server-operator#8
finos/legend-juju-engine-server-operator#9
finos/legend-juju-sdlc-server-operator#10

We can close this issue now.