Revisit the Keycloak Permissions question

[slifty]

In #1093 @bickelj asked some questions about using Keycloak for managing permissions and didn't really get a direct answer (sorry Jesse, there were enough moving parts / trying to scope out the core use cases)!

Right now I'm just about finished with the MVP of our permissions based on which will involve a roles table, but it would be reasonable to take a moment to reflect on what a Keycloak-based granular permissions system would look like and what the benefits / negatives would be.

[bickelj]

I just looked at the latest Keycloak docs. Lo and behold, version 26 has something we might like: Organizations.

In my comment in #1093 I am glad I explicitly linked to the particular minor version of Keycloak I was referring to because that version (one of the versions starting with 25) did not have Organizations.

Off the cuff, a design comes to mind:

• Embrace such Organizations in Keycloak (of course necessitating a Keycloak upgrade).
• Let an Organization in Keycloak be one of PDC-land Funder, Changemaker, or DataProvider.
• Add one (enum-ish) attribute to each Keycloak Organization denoting "this Organization is a Funder" vs a Changemaker or DataProvider.
• Ensure the Keycloak-supplied JWT includes Organization attributes, especially id which should be a UUID.
• An integration with the currently proposed #1284 could be pretty seamless: let the proposed permissions-on-Changemakers/Funders/DataProviders tables set the subject to either a UUID that is a Keycloak ID or an Organization ID. Or we could come up with something else that depends less on our tables and more on Keycloak if we find that possible. But right now my sense is that keeping PDC object permissions in PDC is advantageous.

The net effect of this should be that we can delegate group and user management to Keycloak almost entirely while allowing users in PDC to mark permissions on objects at either a user or group level (where the group is identical with a Keycloak Organization).