2023-06-05 - Consortia Tenant Checks

1 min

Scribe

All

@Craig McNally will take notes.

*

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: Provide ability to perform cross tenant requests for consortia membersClosedPreview

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 onJun 19, 2023