Support custom AuthConfigs to allow OPA use

[jameshbarton]

Is your feature request related to a problem? Please describe. An enterprise customer wants to use OPA to require presence of a specific header in requests, as in this Gloo Edge example. However, custom AuthConfigs are not supported in Portal, as also described in this issue.

Describe the solution you'd like Allow customer OPA policies to be included via custom AuthConfigs.

Describe alternatives you've considered

• Enforce header requirement in OpenAPI spec, perhaps in conjunction with new feature #81 .
• Use a custom WASM filter.
• Use an invertMatch with direct response, something like this (not supported in Portal today):

  kind: VirtualService
  metadata:
  name: test-direct-response
  namespace: gloo-system
  spec:
  virtualHost:
  routes:
  - matchers:
    - headers: 
      - name: header5
  value: value5
  invertMatch: true
    directResponseAction:
      status: 4xx
      body: "Must contain value5"

Additional context Internal discussion: https://solo-io-corp.slack.com/archives/CRV87GM32/p1649356924077649

[soloio-bot]

Zendesk ticket #687 has been linked to this issue.

[bewebi]

The planned approach is to add a CustomAuthConfig field to the UsagePlan object

This field is a reference to an existing AuthConfig PR

Portal will "append" append the logic from the referenced AuthConfig to that which it generates

The UsagePlan will have to have an ApiKey or OAuth policy type; if necessary for the Unauthorized type or a new "custom only" type that would be a separate issue

We will guarantee that Rate Limiting and Try it Out will be functional for OPA, and potentially other config types, but additional config will be needed to be added to the Swagger spec to account for additional auth and we (ideally) will document what is needed there

One nice-to-have is automatic updates for the generated AuthConfig on update to a custom AuthConfig referenced in a UsagePlan, however that may need to be a separate issue

I have sketched the logic for this solution and demonstrated locally that it behaves as intended (ie enforcing the custom auth and respecting rate limiting) for CustomAuthConfig with basicAuth and opaAuth, however formal unit and e2e testing is still required as well as documentation and likely additional logic

I would hope to complete this by mid-to-late next week

[bewebi]

In the process of testing I have determined that combining an OAuth UsagePlan with a custom config that includes Basic auth may not be possible due to ExtAuth limitations I don't believe this is required within the scope of this issue but will call it out in documentation

See this issue for more detail

[bewebi]

I have a draft PR open with CustomAuthConfig functionality implemented, unit tested, and e2e tested for both ApiKey and OAuth usage plans for CustomAuthConfigs with basic auth and OPA auth config types. Note, as mentioned above, that OAuth UsagePlans with basic auth CustomAuthConfig does not work, though this is not within the scope for the issue.

At this point I would like to gather remaining requirements for this issue:

• What level of documentation is required?
  • User facing guide?
  • Detailed comment on the new proto field?
  • Demo video?
  • Details on including required headers in swagger spec?
• Testing for other config types?
  • I would expect not as further issues and PRs can be opened for those
• Do we need Automatic updates to Portal-generated AuthConfigs on update to source CustomAuthConfig?
  • This will be a separate PR regardless and if out of scope for this issue I will open a follow-up issue to be addressed as needed

In the meantime I will work to get the PR closer to review-ready

[jameshbarton]

@bewebi Thank you for your fast work on the custom AuthConfig. RE documentation, there would clearly need to be some updates to the existing auth documentation. An example either in doc or blog form or both would be most welcome. A demo video would be nice but not absolutely essential.

RE testing for other config types, do you think this work will encompass the user-managed / passthrough authZ case? If so, then testing for that case would kill two issues with one stone (and help satisfy a real user requirement).

[bewebi]

solo-io/dev-portal#2397 adds the ability to add a reference to a CustomAuthConfig to a UsagePlan, with e2e testing validating that OPA configs behave as expected when added to a UsagePlan this way

This PR will be released in 1.3.0-beta9 As a net new feature it will not be backported to 1.2

Note that automatic reconciliation of Environments on update to referenced AuthConfigs is not yet implemented and is encompassed in solo-io/dev-portal#2399