Provide full support for api and operation policy declarations
This is a Feature Proposal
Description
Our primary use case for this feature request is to be able to use the validate-jwt policy, but other policies will also be useful.
Some considerations for the implementation:
- Policies are applied as a top-down list, and Operation policies can be inherited from the API policies via the
<base>policy declaration. - A particular policy name can be declared multiple times, and nested within other policy declarations, i.e.:
set-variableandchoose/when/otherwise. - It should be possible to define policies in every section and scope:
inbound,outbound,backend, andon-error. Undefined sections should default to a single empty<base/>policy. - Some discussion maybe useful for how to apply a general policy configuration in the context of the current support for
corsandset-backend-service, i.e. one-or-the-other, or define placeholder tokens for generated CORS/backendId values that can be referenced in general policy configuration.
To add native support should be pretty easy, code-wise. The underlying azure sdk for node already supports creation of these policies in the domain model, and this is how the two explicitly supported policies are created in serverless-azure-functions.
createCorsXmlPolicy(corsPolicy: ApiCorsPolicy)
https://github.com/serverless/serverless-azure-functions/blob/a8629d1277a6dbe35f0973806351f9db810e760e/src/services/apimService.ts#L373-L402
createApiOperationXmlPolicy(backendId: string)
https://github.com/serverless/serverless-azure-functions/blob/a8629d1277a6dbe35f0973806351f9db810e760e/src/services/apimService.ts#L342-L367
Configurations might look like this if the underlying json -> xml mapping is exposed:
apim:
api:
- name: v1
policies:
- inbound:
- "validate-jwt":
...
Or, we could specify a path to a local xml file and define a placeholder syntax for variables, application settings, and generated single-string values.
apim:
api:
- name: v1
policyXml: src/policies/v1.xml
...
Operation policies should be defined as a key of x-azure-settings, and if possible, global scope policies should be defined as a key of provider/apim
Similar or dependent issues:
- #360
@adamcin - Thanks for the feature request. Our goal is to expand support out to support full policy management across APIM but it will take some time.
Right now we do support policy management for JWT validation, CORS, IP filters and other header management. These policies are provisioned at the API level today. This is currently in the dev branch and available as a beta release in NPM.
Let me know if this solves your current requirements
Thanks, @wbreza. I think this gets us closer. My hunch is that we may still need the flexibility to nest the jwt validation in conditional policies in order to allow requests with a JWT header not specified, while denying requests that specify the header with an invalid JWT token.
Is there any way to wrap the jwt validation in choose/when statements at this moment?