2024-05-08 - Architectural PoC part 2

Jenn Colt

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits. 

Discussion on working with authentication and authorization with Keycloak:

• Diagram of user that has permissions
• Keycloak authorization slightly different - concept of capability - explicit granting of ability to perform a specific scope against a particular resource. Separates the resource from the scope. Permission isn't granted permanently, instead there is a policy which allows evaluation at run time whether to grant the permission. User policy, role policy. With Keycloak implementation can deliver either through role policy or user policy, each tied to a capability. Explicit separation between scope and the resource.
• permission has one resource and one scope and multiple policies
• policies are reusable
• interacting with this model strictly through FOLIO. In FOLIO work through more familiar abstraction level - roles and capabilities. capabilities are defined by what endpoints a module has and what scopes are allowed on them. capabilities therefore are system defined.
• what admins can do is create roles. allow particular capabilities that you want to make available to a role and then grant that role to a user.
• current model drawback is it can be hard to determine what has been granted to a user, have to drill into layers of permission sets, hard to evaluate if they have the right level of permissions. in the new model easier to see exactly what capabilities are provided when granting a role to a user, not nested so able to clearly audit and manage what roles have
• what has to happen in development for this to work? shouldn't have to do anything, should be able to use existing modules without modification
• what does that mean in terms of migrating my current set up to this method? have some abilties to do that. can interpret existing perms and create appropriate capabilities. because the assingment is nested and because capabilities generally get assigned as a group, can bundle capabilities into capability sets, system generated, can map existing ui perm sets into pre-determined capability sets and that would be a first step in migration
• capabilities are derived from what the module offers so if module offers resource with a scope that results in the creation of a capability
• don't define capabilities in descriptors, etc. use existing module descriptors
• some module have inconsistency so there is some challenge to make a comprehensive set. would help for some modules to provide declaration and to be consistent in naming
• would be better if things were more uniform but maybe some modules have subtly different desires. does the new way prohibit modules from taking their own approach to bundling permissions? shouldn't. modules can still declare permissions. inconsistency is stuff like GET vs READ. ambiguous action word type that might mean different things in different modules have to be interpreted. we do have some formalization around this, would be good to have more of that, some perms probably existed before the formalization
• back end permissions vs front end permissions - in current model have permissions, back end perm sets, front end sets. in eureka perms are capabilities - back end set = capabilities. front end sets = roles. roles are things you can create, capability sets. the capability sets can be aggregated into roles.
• to operate optimally in eureka, would modules still be backward compatible? there's no way to put capability in module descriptors so basically you keep doing descriptors as you do now with end points and add perms to them, then eureka will create the capabilities
• where is authorization enforced? in the sidecars
• Call starts in UI with user and token, goes to Kong which uses routing tables to figure out how to direct the call, tables point to the sidecar so the call goes there next, the sidecar has awareness of capabilities needed to allow call to proceed so it calls Keycloak which is where enforcement happens, Keycloak validates token and then check keycloak storage to see if that user has the needed roles/capabilities/policies, if so then it tells the sidecar and the sidecar sends the request to the module, then Kong passes the response back to the UI
• these new components are single purpose
• the current approach is less linear, more hub and spoke with okapi at the center
• is there overhead with sidecars? probably less because there are fewer back and forth calls in the more linear eureka model than the hub and spoke okapi model
• authorization is closer to the module with less traffic in the api gateway
• with module to module communication how do the sidecars know where the other sidecars are? at start up the sidecars check in, call the manager, get information from the tenant manager about what module they are associated with and the required permissions, also learns discovery information for the modules its module depends on, also subscribes to a Kafka topic, so if a new tenant or something gets enabled, the new info comes from kafka or new discovery info, etc if something changes.
• now the required interfaces in the module descriptor being described accurately actually matters. in classic FOLIO some inaccuracies didn't matter but in Eureka they matter a lot more because that is how sidecars get info about how to route from module to module.
• right now there are a bunch of missing interface dependencies and they have been filing JIRAs. however there is also a temp mode where if a sidecar doesn't know what to do it can send it to kong instead which will know how to route. log specific warning. fallback mode should be noisy.
• the module sidecars discover based on the interface. what happens if different versions of modules offer same interface version? some modules have large number of interfaces that don't necessarily increment. side car needs to learn about mod-foo discovery info etc, it's not tied to a version of the interface, it's tied to what the tenant has as a specific implementation. can only be one instance of an interface for a tenant at a given time. it gets the bootstrap information that shows dependencies, gets their discovery info for that tenant. right now could deploy two versions of same module in the same installation with different tenants having different versions enabled.  tenant entitlement is part of bootstrap info. not sure if keyed off tenant ID as well.  are you required to have all tenants in one environment on the same release? ID will have env with tenants on different flowers. FSE doesn't do that. Two tenants can currently run different sets of modules in the same env. At A&M when test upgrade versions and when used to do migrations, would leave one tenant alone and make new tenant and enable new and existing modules all in the same instance of FOLIO. Trying to understand how deployments need/don't need to change. Not sure that it is a problem to do. Craig McNally will check on it.
• computational load of one okapi vs many many sidecars? is hub and spoke more cost effective than many side cars? number of api calls is less, not necessarily less resources but sidecars are intended to have very small footprint, Quarkus lets compile to native binaries which helps reduce footprint over jars. Is the new version more resource hungry? Not sure. Previous answer was more about traffic. Same tasks need to be performed regardless of pattern so not sure how much different. In design did want to keep from increasing which is why went with small footprint sidecars but don't have numbers.
• can it continue to run on single machine for folks using that deployment for their development work? this is the vagrant box.
• can we still develop using vagrant boxes? team created docker images that worked, how many modules you can run depends on your machine. all the parts are included in the setup so all containers created.
• TLS communication between Kong and sidecar can they be TLS? module authentication. Kong isn't terminating TLS, sidecar is doing the termination. Kong needs to look into request though. Craig McNally will get back to Julian Ladisch