Update Google auth approach to use new libraries (#166)

* No longer report error for empty lines

* Use newer Google library

* Revised Google auth

* Support redirectParams

* Update documentation

* Tweak schema docs

* Don't actually want to require validDomain

* cleanup

* All logouts using redirect

* Fix issues identified by Angus

* Reading config.ts, RuntimeConfig.dashboardAddress is always defined

config/config_schema.json

@@ -31,7 +31,10 @@
             "additionalProperties": false,
             "required": [
                 "clientId",
-                "userLookupTable"
+                "userLookupTable",
+                "publicKeyLocation",
+                "privateKeyLocation",
+                "issuer"
             ],
             "properties": {
                 "clientId": {
@@ -66,6 +69,61 @@
                     "examples": [
                         "/etc/carta/userlookup.txt"
                     ]
+                },
+                "publicKeyLocation": {
+                    "description": "Path to public key (in PEM format) used for verifying JWTs",
+                    "type": "string",
+                    "examples": [
+                        "/etc/carta/carta_public.pem"
+                    ]
+                },
+                "privateKeyLocation": {
+                    "description": "Path to private key (in PEM format) used for signing JWTs",
+                    "type": "string",
+                    "examples": [
+                        "/etc/carta/carta_private.pem"
+                    ]
+                },
+                "keyAlgorithm": {
+                    "$ref": "#/definitions/keyAlgorithm",
+                    "default": "RS256"
+                },
+                "issuer": {
+                    "description": "Issuer field for JWT",
+                    "type": "string",
+                    "examples": [
+                        "my-carta-server"
+                    ]
+                },
+                "refreshTokenAge": {
+                    "description": "Lifetime of refresh tokens",
+                    "type": "string",
+                    "default": "1w",
+                    "examples": [
+                        "1w",
+                        "15h",
+                        "2d"
+                    ]
+                },
+                "accessTokenAge": {
+                    "description": "Lifetime of access tokens",
+                    "type": "string",
+                    "default": "15m",
+                    "examples": [
+                        "90s",
+                        "1h",
+                        "15m"
+                    ]
+                },
+                "scriptingTokenAge": {
+                    "description": "Lifetime of scripting tokens",
+                    "type": "string",
+                    "default": "1w",
+                    "examples": [
+                        "1w",
+                        "5d",
+                        "10h"
+                    ]
                 }
             }
         },

docs/src/configuration.rst

@@ -43,7 +43,7 @@ The controller signs and validates tokens with SSL keys. You can generate a priv
     openssl genrsa -out carta_private.pem 4096
     openssl rsa -in carta_private.pem -outform PEM -pubout -out carta_public.pem
 
-A public/private keypair is used to authenticate access tokens. OIDC authentication requires an additional symmetric encryption key for refresh tokens. LDAP or PAM authentication uses the same public/private keypair both for access tokens and for refresh tokens. If you use the default encryption algorithm, you can again use `openssl` to generate the needed key:
+In addition to the keypair above for authenticating access tokens and refresh tokens, those using OIDC authentication require an additional symmetric encryption key. If you use the default encryption algorithm, you can again use `openssl` to generate the needed key:
 
 .. code-block:: shell
 

docs/src/introduction.rst

@@ -25,11 +25,12 @@ Detailed installation instructions are available for :ref:`Ubuntu<focal_instruct
 Authentication support
 ----------------------
 
-The CARTA controller supports four modes for authentication. All four modes use refresh and access tokens, as described in the `OAuth2 Authorization flow <https://tools.ietf.org/html/rfc6749#section-1.3.1>`_, stored in `JWT <https://jwt.io/>`_ format. The modes are:
+The CARTA controller supports five modes for authentication. All five modes use refresh and access tokens, as described in the `OAuth2 Authorization flow <https://tools.ietf.org/html/rfc6749#section-1.3.1>`_, stored in `JWT <https://jwt.io/>`_ format. The modes are:
 
 * **PAM authentication**: The PAM interface of the host system is used for user authentication. After the user's username and password configuration are validated by PAM, ``carta-controller`` returns a long-lived refresh token, signed with a private key, which can be exchanged by the CARTA dashboard or the CARTA frontend client for a short-lived access token.
 * **LDAP authentication**: As above, but an LDAP server is used directly for user authentication.
-* **Google authentication**: Google's authentication libraries are used for handling authentication. You must create a new web application in the `Google API console <https://console.developers.google.com/apis/credentials>`_. You will then use the  client ID provided by this application in a number of places during the configuration.
+* **Google authentication**: Google is used at time of login. You must create a new web application in the `Google API console <https://console.developers.google.com/apis/credentials>`_. You will then use the client ID created during the configuration.  You will also need to add a callback URI to your application - e.g. if your application is installed at "https://example.com", you'd want to specify "https://example.com/api/auth/googleCallback" as an authorized redirect URI.
+* **OIDC authentication**: An OIDC-compatible identity provider is used, such as keycloak.
 * **External authentication**: This allows users to authenticate with some external OAuth2-based authentication system. This requires a fair amount of configuration, and has not been well-tested. It is assumed that the refresh token passed by the authentication system is stored as an ``HttpOnly`` cookie.
 
 .. _getting_help: