Ideas on providing authorization to access inputs

[Francis Charette-Migneault]

Description

I would like to gather ideas on how process inputs could be defined during execution to support authorization to access remote URL or S3 buckets.

When a process is protected by some policy enforcement point, the usual approach is to send HTTP Authorization or Set-Cookie headers to grant access. However, after the POST /processes/{id}/execution request was authorized, the inputs defined in the execution body could themselves be href to other locations that also require authorization, and which doesn't necessarily match the same HTTP authorization used to POST the execution. An obvious example would be a protected S3 bucket with files that would almost certainly have different access credentials than the server running the OGC API - Processes service.

One quick fix approach could be to employ additionalParameters in the corresponding input that requires this kind of authorization. The necessary structure of additional parameters is not obvious (nor standardized) however, considering there are also multiple ways to define authorizations (basic, bearer token, cookies, etc.). There is no clear way how those parameters should be defined and handled to form some HTTP Authorization header when requesting the file.

ogcapi-processes/openapi/schemas/processes-core/descriptionType.yaml

Lines 15 to 23 in bfaf8f0

 additionalParameters: 
   allOf: 
     - $ref: "metadata.yaml" 
     - type: object 
       properties: 
         parameters: 
           type: array 
           items: 
             $ref: "additionalParameter.yaml" 

Open Questions

1. Would additionalParameters be the best strategy?
2. If so, could OGC API - Processes provide recommendations and OpenAPI schema definitions on the expected formats?
3. Has anybody used this additionalParameters approach to confirm it is viable?
4. Otherwise, what other alternative would be possible, and what are the tradeoffs of their advantages/disadvantages?