Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-2583

Spike: Distributed configuration

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Open (View Workflow)
    • Priority: P3
    • Resolution: Unresolved
    • Component/s: None
    • Labels:
      None
    • Template:
    • Sprint:
      CP: Non-roadmap backlog
    • Development Team:
      Core: Platform

      Description

      Overview

      One outcome of FOLIO-2565 is that centralized configuration via mod-configuration is problematic from a security perspective. It provides a convenient mechanism for storing configuration, but the permission granularity is too coarse. Granting a user the ability to access an entry for one app means that they will also have access to ALL configuration entries.

      An idea was proposed that all modules have a system interface which can be implement (or not), that presents a common interface for accessing configuration specific to various modules.

      e.g. each module would have the opportunity to implement the "config" interface and implement:

      • GET /configurations/entries
      • GET /configurations/entries/<id>
      • POST /configurations/entries
      • PUT /configurations/entries/<id>
      • DELETE /configurations/entries/<id>

      Each of which would be protected by discrete permissions, e.g. mod-foo might have:

      • foo.configurations.collection.get,
      • foo.configurations.item.get (put/post/delete)

      Acceptance Criteria

      • The following questions should be answered
        • Feasibility of this idea - a POC might make sense
        • What would adoption of this look like? Is an opt-in model viable?
        • Are there other aspects to this that should be considered in the decision making process?
          • Sample/Reference data loading - seems like a win to me over centralized configuration
          • Default implementation by RMB? Reference implementation?
          • Impact to the UI?
          • Optional use of permissionsDesired to offer even finer grained access control?
          • Ability to incorporate secret storage (encryption at rest) in the future, i.e. via extension of this API?
      • Documentation of the high level design on the wiki
      • User stores are created for implementation

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                cmcnally Craig McNally
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases