Adds access / requestor workflow

This PR adds:

access module that interfaces w/ Gen3's requestor, see tests/integration/test_access.py for simple workflow

Enables `User` and `Someone who makes access decisions`

From Requestor's documentation

specifically:

gen3_util access touch USER_NAME RESOURCE_PATH implements Fill out access request form
gen3_util access update REQUEST_ID STATUS implements update access request status
gen3_util access ls implements send form data

see https://github.com/uc-cdis/requestor/blob/master/docs/functionality_and_flow.md

---/---

Usage: gen3_util access [OPTIONS] COMMAND [ARGS]...

  Manage access requests.

Options:
  --help  Show this message and exit.

Commands:
  touch   Create a request for read access.
  update  Update the request's approval workflow.
  ls      List current user's requests.
  cat     Show details of a specific request.

Notes:

Arborist has a usr table, full of users synced from user.yaml. It also has tables usr_grp, grp and grp_policy all populated from the user.yaml sync. Arborist also has apis to add users, groups etc. They are not exposed outside of the cluster. This is probably a good idea. Appropriately, it is up to something within the cluster to access those APIs, in this case Requestor.

Requestor will read policies and permissions from arborist regarding a users ability to request and grant access by user. e.g: user.yaml

docker-compose snippets:

  requestor-service:
    build: requestor
    # image: "quay.io/cdis/requestor"
    container_name: requestor-service
    networks:
      - devnet
    volumes:
      - ./Secrets/requestor-config.yaml:/src/requestor-config.yaml
    environment:
      - DB_DATABASE=requestor_db
      - DB_USER=XXXXX
      - DB_PASSWORD=XXXXX
      - DB_HOST=postgres
      - DB_PORT=5432
      - PGSSLMODE=disable
      - GEN3_ARBORIST_ENDPOINT=http://arborist-service
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost/health"]
      interval: 60s
      timeout: 5s
      retries: 10

    # note: requestor's auth client get's the "iss" claim of the JWT token and will connect and validate against that url.
    # therefore, if that endpoint is not a public DNS entry, the requestor's container needs to resolve that host    
    # eg.
    extra_hosts:
     - "aced-training.compbio.ohsu.edu:THE-IP-ADDRESS-OF-THE-HOST-OS"

revproxy-service nginx snippet:

      location /requestor/ {
          rewrite ^/requestor/(.*) /$1 break;
          auth_request_set $saved_set_cookie $upstream_http_set_cookie;
          proxy_pass http://requestor-service/;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $http_connection;
            proxy_set_header Authorization "$access_token";
            client_max_body_size 0;
      }

postgres setup:

In scripts/postgres_init.sql

CREATE DATABASE arborist_db;
CREATE USER requestor_user;
ALTER USER requestor_user WITH PASSWORD 'XXXXX';
ALTER USER requestor_user WITH SUPERUSER;

helm The helm chart seems complete. We have yet to test.

See more:

https://github.com/uc-cdis/requestor/blob/master/docs/authorization.md

ACED-IDP / gen3_util