Support partitioning collections by schema

[dr-jts]

A common use for database schemas is to partition data by access policy. They are also used as a mechanism to manage large numbers of tables. It would be nice to support these use cases in the API and UI.

There are two main reasons to support partitioning by schema:

• Security - allow access to be controlled via simple proxy URL rules based on schema
  • Note that if access to a schema is disallowed external to the service, if the service provides a list of schemas then this may not reflect users actual access capabilities
• Usability - This includes reducing size of collections list metadata response and improving readability of UI collections list page, for large numbers of schemas and tables

Design Goals

• Do not provide a list of schemas (in UI or metadata). This avoids exposing schema names to which user does not have access
• Be as consistent as possible with OGC API

Design Questions

• Should there be a way to list available schemas (in UI and/or metadata) ? If so, how can this reflect access control policies?
• Is it necessary to provide both current mode (all tables) and schema-partitioned mode in a single service instance? Or should there just be a config switch to choose modes of operation?
• What is returned by the collections path?
  • Simplest is to just return Invalid
  • Alternative is to provide list of schemas (but this probably means that access to this page should be limited to admin users)
• What should appear on the API landing page?
  • simplest is just to omit link to collections

Design Proposal

The schema name is specified as prefix to the OAPIF path (instead of in the collection name). E.g.:

http://localhost/schema/collections/collname

This allows URL rules to define access rights to collections by schema.

The path http://localhost/schema/collections provides a list of collections within the schema (identical to the current collections path).

The simplest solution is to make this a different mode of operation. A configuration parameter determines which is provided by a service.

Note that access to functions is not affected by this change.

[smnorris]

If I want to serve tables from the same db with two different access policies, it looks like the easiest way to do it currently would be to create two roles and config files, and run two pg_featureserv instances?

[pramsey]

For now, yes, one instance with each access policy you want.