No internet connection
  1. Home
  2. Support

Pointing Talkyard to a GitLab oauth 2 authentication provider

By @byosh
    2020-08-14 23:54:04.789Z

    Hi, I've been trying to set up an on-prem, airgapped Talkyard instance, and wanted to leverage the oauth2 provider feature on our on-prem GitLab instance.

    I tried to read through this documentation as a reference: https://docs.gitlab.com/ee/integration/oauth_provider.html

    Unfortunately, nothing play-framework.conf lines up with the instructions given. I tried to fake things out by substituting values for github, and it does jump to the GitLab authentication, but then fails when it tries to redirect to an invalid URI.

    I also tried to look at the SSO section in the configuration, but this didn't line up with any other available documentation.

    Is it possible to add a new section in silhouette to insert a new oauth provider?

    (Our instance is running on CentOS 7.5 running docker)

    Thank you in advance,

    Ben

    Reply
    • 8 replies
    1. KajMagnus @KajMagnus2020-08-15 04:25:09.200Z2020-08-15 06:32:34.965Z

      Would you like to post your GitLab play-framework.conf config (that results in the "redirect to an invalid URI" problem) ?
      With the client ID & secret etc edited out, maybe the hostname replaced with example.com?
      [Edit] If you want, you could send that in a private message [/Edit].

      Ought to be possible to get this working, via a new section Silhouette.

      Also, within 2 weeks probably, Talkyard will suport OIDC (OpenID Connect, built on top of OAuth2).
      GitLab can be an OIDC identity provider: https://docs.gitlab.com/ee/integration/openid_connect_provider.html,
      so that will be a 2nd way to integrate with GitLab.

      ***

      airgapped Talkyard instance

      How nice, I creted a topic abou that here: https://www.talkyard.io/-422/air-gapped-talkyard

      Reply
      1. B@byosh
          2020-08-19 18:48:20.971Z

          Thanks for the quick response (I was out of the office for a couple of days, unfortunately)

          Here is a snippet of the play-framework.conf file:

          silhouette {
          ...
          github.authorizationURL="http://<gitlab host>/gitlab/oauth/authorize"
          github.accessTokenURL="http://<gitlab host>/gitlab/oauth/access_token"
          github.scope="read_user email"
          github.clientID="<client ID>"
          github.clientSecret="<client secret>"
          }

          After authenticating, with the GitLab server, it replies with "The redirect URL included is not valid" and the auth window shows the following URL (in the browser's address feld, all one line):

          http://<gitlab host>/gitlab/oauth/authorize?scope=read_user+email&client_id=<client ID>&response_type=code&state=<hash string>&
          redirect_uri=<escaped URI of http://<talkyard host>/-/login-auth-callback/github>

          Is there any documentation regarding a "new silhouette section" as you mention?

          Thanks for all your help, and for creating this.

          I noticed that when I do a docker-compose restart, things like the talkyard_search_1 seem to take a while to restart, but I'm assuming it's trying to call out and timing out. Otherwise things seem to be working fine.

          Ben.

          Reply
          1. KajMagnus @KajMagnus2020-08-19 19:36:18.898Z

            In the play-framework.conf snippet, I see github. ... instead of GitLab, e.g. github.authorizationURL = .. I wonder if that is a typo in this question only, or in the actual config?

            Here's Talkyard's GitLab config value names: (in this case not wrapped in silhouette { ... }, instead, on each line, doesn't matter)

            silhouette.gitlab.authorizationURL
silhouette.gitlab.accessTokenURL
silhouette.gitlab.clientID
silhouette.gitlab.clientSecret
silhouette.gitlab.scope

            (the same as here: https://www.silhouette.rocks/docs/config-oauth2-based-providers#example )

            The redirect URL you pasted mentions both GitHub and GitLab — GitHub once at the very end:
            http://<gitlab host>/gitlab/oauth/authorize?scope=read_user+email&client_id=<client ID>&response_type=code&state=<hash string>& redirect_uri=<escaped URI of http://<talkyard host>/-/login-auth-callback/github
            — that's because the previous many-lines snippet said github. ... but should be gitlab. .....

            ***

            talkyard_search_1 seem to take a while to restart, but I'm assuming it's trying to call out and timing out

            Hmm. Restarting. — It takes long to stop, before starting again? Or takes long to start, after having stopped already?
            The former can happen if Talkyard's Docker entrypoint or ElasticSearch RUN command doesn't react properly to SIGTERM events.

            Reply
            1. B@byosh
                2020-08-19 19:46:25.018Z

                Hello again,

                The snippet is exactly as it was configured -- I was trying to fake the gitlab and see how far it would take me.

                I just tried using the lines as you specified, but there is no means to enable GitLab as an authentication choice. This is in the admin area in "Ways to sign up". I tried to add those lines, but there is no way to enable GitLab.

                Thanks,

                Ben

                Reply
                1. KajMagnus @KajMagnus2020-08-20 18:49:13.696Z

                  Then I think I understand. I'll need to add GitLab login buttons, client (browser) side — I'll do, and I can probably have this ready on Monday next week. (I'll download GitLab CE and verify this will actually work.)

                  Reply
                  1. B@byosh
                      2020-08-20 19:08:40.669Z

                      Hi KajMagnus,

                      Thank you! The only trick at this point is that I can't upgrade the usual way. When I set up my VM, it was during telework, but now that I have deployed it, I probably need to study your pull request and apply changes manually.

                      Ben.

                      Reply
                      1. KajMagnus @KajMagnus2020-08-23 04:53:08.982Z

                        Hi Ben, This'll take longer (sorry) — I'm fixing an unrelated bug right now (about moderators reviewing & approving posts).

                        need to study your pull request and apply changes manually

                        Ok, that sounds like patching source code? Or what does apply changes manually mean (in this context)?

                        Reply
                        1. B@byosh
                            2020-08-24 17:32:21.044Z

                            Hello KajMagnus,

                            There's no rush, so please don't worry about it on my end. My comment pertains to my particular work environment.

                            Our main systems are on an air-gapped environment, although we have been setting up VMs (typically when we are allowed to telework) where Internet is available.
                            We then transfer the virtual-hard drives in to our environment and move them into environment, adjusting the parameters to properly work in the air-gapped environment.

                            To apply patches or changes, I could (at home, in my case) open up the original VM I used, and apply a git pull origin master and then run the appropriate scripts to retrieve the necessary docker image changes. (Or I could follow my own notes to re-generate the VM from scratch.)

                            Unfortunately, for the instance already installed within the air-gapped environment, there is no straightforward way to apply and update the patches, and any docker images which may be necessary. I suppose for the git-side, I could git bundle, but I think the docker side complicates things, since it's not straightforward.

                            Thanks in advance!

                            Ben.

                            Reply
              ReplyAdd progress note