2023-06-05 - Consortia Tenant Checks

All 

Background: 

• There's a proposal to relax the tenant check in the context of consortia/cross-tenant support which has raised concerns from some. 
• See Enhanced Consortia Support(ECS)
• MODAT-143 - Getting issue details... STATUS

Discussion Notes:

• Much of this work has already been done. 
• Marc Johnson What is the relevance of this to the conversation?  
  • Jeremy Huff If there are security concerns which require changes to be rolled back, that's something we should discuss, even if it's inconvenient.
• Olamide Kolawole provided a walkthrough
  • 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.
• Maccabee Levine how are users/shadow users linked?
  • They share the same UUID.
• 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 on19 Jun 2023