Improve handling of credentials for service calls

[ebruchez]

UPDATE 2022-03-28 @avernet: See @ebruchez's 2021-08-02 comment for concrete use case.

UPDATE 2022-03-28: RESOLUTION: We will change the FormRunnerAuthFilter not to filter the Orbeon-Username, Orbeon-Roles, and Orbeon-Group for requests to /fr/service/*. This way, services callers will be able to make queries "on behalf of someone". Also, customers can set up their authorizer to altogether reject requests with those headers set, of check that the values of the headers are allowed depending on some custom logic.

See #2275 for the a concrete issue.

• A service must not only be authorized by the authorization service, but username, group and role must be provided.
• Those can be returned by the service as Orbeon-Username, Orbeon-Group, and Orbeon-Roles.

Questions:

• Those headers are now set in FormRunnerAuthFilter. But service authorization is done by the PFC. If the PFC obtains headers, how should they be passed? Maybe by wrapping the ExternalContext in PageOrServiceRoute.process(), so that they are in effect only for the rest of the request.
• Should we instead have a servlet filter matching on /fr/service to call the authorizer and set the headers?

[ebruchez]

+1 from customer

[ebruchez]

Comment from duplicate #1872 which I just closed:

The Form Runner persistence API needs to know about the current user (username, roles, and group) to return meaningful results. For this information to be available to the API when it is called by a 3rd-party application, currently Orbeon Forms needs to be deployed twice:

1. Once setup with FORM-based authentication (to be accessed by end-users with a browser).
2. Once with BASIC authentication (to be accessed by 3rd-party applications).

We would like to avoid the need to deploy Orbeon Forms twice. One way to do this would be to:

1. Use a single war, disabling authentication for the services (this is already what is being done by default).
2. In the PFC, when calling the authorization service, pass the list of roles in a header.
3. In our simple authorizer, use that list of roles, and set the Orbeon-Username, Orbeon-Group, and Orbeon-Roles in the response.
4. In the PFC, when an authorization service returns those headers, use their value and take that to the be the authenticated user.

[ebruchez]

Do we have a workaround for this, or not? If not, then we need to implement this quickly.

Here is a concrete scenario causing problems:

• app is protected with BASIC auth
• services are, as is standard, not protected at that level
• however services are protect via the orbeon-auth webapp
• search service is properly authorized this way
• however the search service doesn't have incoming username/roles headers
• so it filters the results accordingly
• but the caller would like to be able to say, for example, that the orbeon-service role applies

[avernet]

+1 from customer

[ebruchez]

• [x] implement in FormRunnerAuthFilter
• [x] doc
• [x] unit test
• [ ] manual test
  • [ ] test that auth still works properly for pages
  • [ ] test that we can authenticate and impersonate user in service calls

[ebruchez]

Documented

[ebruchez]

Reopening until we have properly tested.