James keycloak integration

[JPadovano1483]

Current changes:

• initialized keycloak to enforce user authentication to use the console and block certain api endpoints to only allow specific realm roles
• enforce RLS on certain database tables (currently backbones and applicationnetworks) to allow users to access only rows they either created or someone in one of their groups created
• added wrapper function for database queries to always set necessary postgres session variables in order to use tables with RLS enabled
• created new user table to map keycloak user id's to postgres user uuids (postgres uuids are used for RLS enforcement)
• added system user in the postgres database to allow for the app to still make database queries outside the context of the api and RLS

Some thoughts about where to go from here:

• looking into switching from using a system user for these system calls to creating a separate database role that can bypass RLS and using separate connection pools for system generated database queries vs user generated queries
• will need to discuss how to properly configure keycloak and postgres RLS policies to properly allow users to access resources created by their group without accidentally accessing something created by someone in multiple groups that happens to overlap
• make some efficiency improvements (adding where clauses to queries so were not solely relying on RLS to filter returned rows, maybe cache user id for something like 5 minutes to limit number of queries)

[ted-ross]

A few suggestions and comments for discussion.

[JPadovano1483]

@ted-ross Here are the changes I made after our conversation last week.

• removed the "system user" and implemented two connection pools, one for system calls to be made through and one for api function calls to be made through.
• reverted system calls to use old format for now (no queryWithContext) in order to make this PR less noisy. Ultimately, we may want to have all db queries use queryWithContext, although not needed other than for consistency.
• Added dropdowns on backbone, library block, application, and deployment creation pages, to specify group ownership of an object. When a van is created, it is given the same group ownership as the backbone it is connecting to (can change this to have the same dropdown as the other objects if that makes more sense). The dropdown displays all groups a user is part of, meaning they can only give ownership of an object to a group they are a part of.
• added WHERE clauses to all queries that reference a table with RLS on it. These are effectively redundant as RLS will filter returned rows in the same way, but it seems to be best practice to not directly use RLS to filter.

We will still need to discuss finalizing a keycloak configuration (such as how granular we want to make keycloak realm roles) as well as if there are other tables we want to add rls policies for.

[ted-ross]

There's an important change needed: The scripts/drop.sql file must completely un-do everything created in the scripts/db-setup.sql file.

[JPadovano1483]

There's an important change needed: The scripts/drop.sql file must completely un-do everything created in the scripts/db-setup.sql file.

Ahh yup, I'll add that in.

[JPadovano1483]

Main changes:

• added RLS policies to BackboneAccessPoints, InterRouterLinks, and InteriorSites tables
• added user/group ownership to rows in those tables
• added granular per-endpoint realm role checks in the APIs

[JPadovano1483]

I added one more realm role to allow van-owners to read access points on the backbone they are connecting to.