0 Fork 0

Files

T

Elim Tsiagbey 8b8d2822df feat(oidc): OIDC Prompt (#4053 )

Boundary OIDC method does not currently support passing in prompts during authentication. This change adds the capability of passing OIDC prompts. Prompts are optional OIDC parameters that determine the behaviour of the authentication server: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

## Changes

- New `auth_oidc_prompt` table which contains all the prompts for OIDC auth method
- New `auth_oidc_prompt_enm` table which contains possible enum values for a prompt
  - Currently supported:
    - `none`: 
The Authorization Server MUST NOT display any authentication or consent user interface pages
    - `login`: The Authorization Server SHOULD prompt the End-User for reauthentication
    - `consent`: The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client
    - `select_account`: The Authorization Server SHOULD prompt the End-User to select a user account
- `oidc_auth_method_with_value_obj` view has been updated to return `prompt` value
- Add `prompt` option for OIDC auth method CLI create and update
- Pass configured prompt during OIDC authentication
- Add `prompt` API validation for create and update

2023-11-21 11:30:02 -05:00

initdb.d

[COMPLIANCE] License changes (#3567 )

2023-08-11 10:31:53 -07:00

tests

feat(oidc): OIDC Prompt (#4053 )

2023-11-21 11:30:02 -05:00

Makefile

feat(oidc): OIDC Prompt (#4053 )

2023-11-21 11:30:02 -05:00

README.md

fix(db): Fix time zone consistency issues in monthly billing views

2023-06-05 12:48:15 -04:00

README.md

SQL Tests

This test suite is used to test behavior of the database logic. In particular the data warehouse implementation is completely in sql via plpgsql, functions, and triggers. This test suite is also implemented directly in sql.

Organization

initdb.d: contains init scripts/sql that is run on the test database when it starts. It ensures the sql migrations are run and creates test helper functions.
tests: contains the tests. Each file can contain only a single test that runs in a transaction so it can rollback.

The tests leverage the pgTap postgres extension to make assertions and provide more readable test output.

Usage

To run the test run make or make test. This will:

Start a docker postgres container and initialize it.
Start a docker pgtap container to execute the tests.

When writing new tests it can be faster to keep the database up and just re-run the tests. This can be done by running:

# starts database docker image in the background
make database-up

# runs the tests, call this multiple times while implementing new tests.
make run-tests

# to clean up
make clean

You can also run individual tests:

# run a single test file
make TESTS=tests/setup/wtt_load.sql

# run a single test file with the database already created.
make run-tests TESTS=tests/setup/wtt_load.sql

# run a directory of tests
make TESTS=tests/setup/*.sql

You can pass through options to pg_prove. See the docs for available options, i.e:

# run tests in parallel with verbose output
make PROVE_OPTS='-j9 -v'

By default the database docker container does not use a host port. This can be changed using an environment variable:

$ export SQL_TEST_DB_PORT=5433
$ make database-up
$ make run-tests

Different versions of postgres can easily be tested:

make PG_DOCKER_TAG=latest
make PG_DOCKER_TAG=14-alpine
make PG_DOCKER_TAG=13-alpine
make PG_DOCKER_TAG=12-alpine