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

Create Auth-Z filter (split Keystone v2 filter)

    Details

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

      Description

      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.

      Scope
      A previous story handled splitting out the common code to another module. This 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.

      Splitting
      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.

      DD
      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:
      https://stackoverflow.com/questions/21586396/generate-only-unique-jaxb-objects-for-schema-containing-multiple-import-schemas

      X-Tenant-Id Header
      For the X-Tenant-Id header, we want to be able to get tenants from the URI, a header, the body, or a query parameter, maybe even in the same request (e.g. one tenant from the URI and a second tenant from a header). For backwards compatibility, we will continue to support grabbing the a tenant from the URI. We will also try grabbing a tenant from a header. The second part will open up the possibility of getting a tenant from the body or query parameter. When we match on multiple tenants, they will get the same quality (i.e. q=1 or whatever we default the quality to). The header that we look in for tenants will be configurable. The value will be assumed to be splittable. We should also validate the values in that header.

      Acceptance Criteria:

      • The Keystone v2 filter is split into two filters with the first one doing authentication and the second doing authorization.
      • The Keystone v2 filter maintains backwards compatibility with the authorization code being marked deprecated.
      • There is a new configuration option to pull the tenant for the request from a header in addition to the URI (for backwards compatibility).
      • Docs are updated to mention the deprecation of auth-z in the Keystone v2 filter and recommendation of the new filter.
      • When the config is read (e.g. during Repose startup), a deprecation warning is logged when a config option that will be moved to the new filter is used.

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                damien.johnson Damien Johnson
                Reporter:
                mario.lopez Mario Lopez
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: