OAuth for Traefik Gateway
+The traefik gateway is used to serve the DTaaS. All the services +provided as part of the application are secured at the traefik gateway. +The security is based on Traefik forward-auth.
+An illustration of the docker containers used and the authorization +setup is shown here.
+ +The traefik forward-auth can use any OAuth2 provider, but within the DTaaS +gitlab is used as authorization provider. +You will use +the OAuth the web / server application +authorization flow.
+Here are the steps to get started:
+1. Choose Your GitLab Server:
+-
+
- You need to set up OAuth authorization on a GitLab server. + The commercial gitlab.com is not suitable for multi-user authorization + (DTaaS requires this), so you'll need an on-premise GitLab instance. +
- You can use + GitLab Omnibus Docker for this purpose. +
- Configure the OAuth application as an + instance-wide authorization type. + Select option to generate client secret and also selection option + for trusted application. +
2. Determine Your Website's Hostname:
+-
+
- Before setting up OAuth on GitLab, decide on the hostname for your website. + It's recommended to use a self-hosted GitLab instance, which you will use in + other parts of the DTaaS application. +
3. Define Callback and Logout URLs:
+-
+
- For the web / server authorization flow to function correctly, you need two URLs: + a callback URL and a logout URL. +
- The callback URL informs the OAuth provider of the + page where + signed-in users should be redirected. It is the landing + homepage of the DTaaS applicati1on. + (either http://foo.com/Library/ or http://localhost/Library/) +
- The logout URL is the URL for signout of gitlab and clear authorization + within traefik-forward auth. + (either http://foo.com/_oauth/ or http://localhost/_oauth/) +
4. OAuth Application Creation:
+-
+
- During the creation of the OAuth application on GitLab, you need to specify + the scope. Choose read_user scope. +
5. Application Credentials:
+-
+
- After successfully creating the OAuth application, GitLab generates + an application ID and client secret. + Both these values are long string of HEX values that you will need for + your configuration files. +
6. Required Information from OAuth Application:
+-
+
- You will need the following information from the OAuth application + registered on GitLab: +
GitLab Variable Name | +Variable Name in .env of docker compose file | +Default Value | +
---|---|---|
OAuth Provider | +OAUTH_URL | +https://gitlab.foo.com/ | +
Application ID | +CLIENT_ID | +xx | +
Application Secret | +CLIENT_SECRET | +xx | +
Callback URL | +(to be directly entered in Gitlab OAuth registration) | ++ |
Forward-auth secret | +OAUTH_SECRET | +random-secret-string (password for forward-auth, can be changed to your preferred string) | +
Scopes | ++ |
Development Environment
+The development environment does not required traefik forward-auth.
+Configure Authorization Rules for Traefik Forward-Auth
+The Traefik forward-auth microservices requires configuration rules to manage +authorization for different URL paths. +The conf file can be used to configure the specific rules. +There are broadly three kinds of URLs:
+Public Path Without Authorization
+To setup a public page, an example is shown below.
+ +Here, 'noauth' is the rule name, and should be changed to suit rule use. +Rule names should be unique for each rule. +The 'action' property is set to "allow" to make the resource public. +The 'rule' property defines the path/route to reach the resource.
+Common to All Users
+To setup a common page that requires Gitlab OAuth, +but is available to all users of the Gitlab instance:
+ +The 'action' property is set to "auth", to enable Gitlab +OAuth before the resource can be accessed.
+Selective Access
+Selective Access refers to the scenario of allowing access to a URL path +for a few users. To setup selective access to a page:
+The 'whitelist' property of a rule defines a comma separated list +of email IDs that are allowed to access the resource. +While signing in users can sign in with either their username or email ID +as usual, but the email ID corresponding to the +account should be included in the whitelist.
+This restricts access of the resource, +allowing only users mentioned in the whitelist.
+Limitation
+The rules in conf file are not dynamically loaded into +the traefik-forward-auth microservice. +Any change in the conf file requires +retart of traefik-forward-auth for the changes to take effect. +All the existing user sessions get invalidated when +the traefik-forward-auth restarts.
+Use a simple command on the terminal.
+ + + + + + + + + + + + + +