Uploaded image for project: 'Repose'
  1. REP-6390

Move Keystone v2 common code to different module (split Keystone v2 filter)


    • Type: Story
    • Status: Resolved (View workflow)
    • Priority: Medium
    • Resolution: Done
    • Affects versions: None
    • Fix versions:
    • Components: None
    • Labels:
    • Sprint:
      Sprint 157, Sprint 158, Sprint 159
    • Story Points:
    • Capitalizable:


      Among other reasons, in order to allow APIs to use their own logic to determine the tenant for a request, we should split the Keystone v2 filter into multiple filters.

      This story will specifically handle splitting out the common code to another module. Another story will handle creating the new filter.

      Filters, Headers, and Attributes
      We will be splitting the Keystone v2 filter into two filters. The first filter will be putting some of the values into headers (for values that people would want even when they don't have the auth-z filter) and will put some values needed by for authorization into attributes. The auth-z filter will read those attributes, makes some determinations, and then populate the other headers (to cover all of the headers the Keystone v2 filter currently populate). We'll figure out which filters will write out which headers while we work the story.

      Episodes, JAXB, and Shared Config
      We'll have three schemas, the common stuff, and the stuff for each filter. Without episodes, JAXB would create the common stuff twice when building. Episodes is a way to tell JAXB not to be silly. We may need to update some of our dependencies to support the episodes functionality appropriately. We may also need to make changes to the JAXB Gradle plugin.

      Authorization goes in the auth-z part and authentication goes in the auth-n part. The auth-n filter will support both to maintain backwards compatibility, and the authorization logic will be marked deprecated.

      The auth-z filter probably won't need the DD.

      From the spike:
      So right now I'm leaning toward using attributes for transport between the filters. The auth-n filter will not try to write the tenant header based on url. Instead we will add another type of element to validate tenant that allows the specification of a header for the tenant we wish to authorize. Using episodes we should be able to make one set of configuration objects that we just reuse in both configurations. This will also let us section out the auth-z parts and just make those parts of the code take the configuration as an additional argument.

      This is potentially relevant:

      Acceptance Criteria:

      • The Keystone v2 filter code that will be common to both filter is moved to a different module in preparation for splitting the Keystone v2 filter into two filters.


          Issue links



              • Assignee:
                adrian.george Adrian George
                mario.lopez Mario Lopez
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: