Consortia is comprised of two or more member libraries
Consortia members collaborate and work together
mod-consortia is optional - single-tenant deployments of FOLIO are not required to run this module and should be unaffected.
In this case the tenant check has not been changed
The functionality allows one tenant to make calls to make API calls against another tenant by changing the x-okapi-tenant header (cross the tenant boundary)
The authentication and authorization processes are still in place
Marc Johnson how does the tenant check remain unchanged if mod-consortia is not being used?
Olamide Kolawole user/consortia member affiliations are captured in mod-users
What part of the system is verifying that the user is associated with the tenant which they're trying to interact with?
Mod-authtoken is responsible for this.
Jeremy Huff mod-authtoken does this by calling mod-users?
Olamide Kolawole In some cases, e.g. if authorization fails, yes.
mod-authtoken was already calling mod-users for other purposes
Olamide Kolawole Even if you're able to spoof the kafka message and mod-authtoken allows a user to call another tenant, the (shadow) user still needs to pass authorization (permission) checks in the target tenant
This happens without requiring the user to authenticate (log in) again against the target tenant.
Olamide Kolawole in the interest of time, we should try to focus on the tenant separation part of this during this meeting
How are permissions handled?
Users and their corresponding shadow users are managed independently
Shadow users are not created with credentials - you won't be able to log in directly as a shadow user.
Users are still managed via mod-users. Kafka messages are published when users are created. These messages are consumed by mod-consortia, which then interacts with mod-users to create the shadow users in other tenants.
Axel Dörrer when is mod-consortia allowed to create shadow users in other tenants? From any tenant context?
mod-consortia creates shadow users in other tenants when a user's affiliations are set/changed. Mod-consortia performs the tenant context switch in order to create the shadow user.
How does mod-consortia do this if permissions don't cross tenant boundaries?
Mod-consortia has module permissions to create users in other tenants
In effect module permissions DO cross tenant boundaries
Marc Johnson currently module permissions are defined in the context of a given tenant (the module is enabled for a tenant)
Olamide Kolawole mod-consortia is enabled in all tenants involved.
System users exist in each of the tenants
Craig McNally we're running out of time, how shall we proceed?
Jeremy Huff Now that we have more background, I'm better prepared to have an in-depth conversation about the concerns.
Suggestion: Get another Monday meeting scheduled to continue this discussion. Probably on
Today's Discussion Notes:
Axel Dörrer : Understand there's a switch to disable tenant sepration for this. How to confirm that only this switch can do so?
Olamide Kolawole : Requires presence of the mod_consortia module and enabling it.
Marc Johnson : Understand we are removing checks for which tenant. As long as user has relevant permissions in destination tenant, we don't check that the two tenants are the same. If so, then that's available to any FOLIO system regardless of consortium module present?
Olamide Kolawole : mod_token checking tenant id. If it sees a mismatch, then further check to see if consortia involved. User also has to be represented in destination tenant. A FOLIO cluster that does not have mod_consortia enabled, if for some reason you could make a call to another tenant somehow, you would still need a user in that tenant.
Axel Dörrer I would have a main/super tenant, contain all credentials of the consortia users. Log into each tenant via SAML. Would have preferred this model, but might not serve the planned data exchanges.
Olamide Kolawole Level of data exchange needed requires objects crossing tenant boundary. Consortium functionality built on top of FOLIO, so user objects in one tenant can't access other tenants. Creating separate user representations keeps that separation.
Marc Johnson Axel's proposal, sitting outside FOLIO system, instead of weakening tenant separation, Drafted proposal is more of a change to FOLIO inside – changing auth-token to know about consortia.
Maccabee Levine Integration testing should be much greater than normal. Testing access attempts that should fail. All permutations that Olamide described. Bugs can creep in.
Olamide Kolawole Default state doesn't allow cross-tenant. And need user with exact UUID. All tests are string equality, so not inherent complexity. But concern is valid.
Marc Johnson Seems not simple, a lot of complexity added to mod_auth_token.
Olamide Kolawole Most complexity added to mod_consortium. mod_auth_token changes are simpler.
Marc Johnson how does mod_auth_token know about consortial setup?
Olamide Kolawole table in mod_users. still uses mod_login for other tenants and to verify all the things lt does today.
Olamide Kolawole Without this work, UI would need a token for every tenant. This way, client only needs one set of credentials.
Marc Johnson If some other client pushes data into mod_users about cross-tenant requests, then those can occur even if mod_consortia not enabled.
Olamide Kolawole Spoofing Kafka message mod_users is listening to. mod_auth_token would allow the request through. But still hit the same user permission hurdles after, same that exist today.
Marc Johnson So even if consortia stuff turned off, you can still have cross-tenant requests going on, after those Kafka messages. Any module can fill the role of mod_consortia and send the right messages to allow that access. No access control on that in Kafka (out of scope with sysops, not baked into FOLIO). Permissions check is good, but user doesn't have to have the same authentication.
Axel Dörrer Agree on Marc's concern. Rogue module. Be aware of. Functionality should be well-verified and well-tested. Suggest external / independent verification of paths.
Olamide Kolawole Agree it's possible with rogue module. If it can create a user with exact same ID. Then other issues exist, larger, attacker is well-embedded. Will bring back that feedback to see how we can act on it.