New filter-based design for the API authentication mechanisms

[GPortas]

Overview of the Feature Request

Instead of calling the AbstractApiBean's findUserOrDie method on each secured endpoint to authenticate the request through one of the possible authentication credentials, this responsibility can be delegated to an outer layer. Since Dataverse already uses the JAX-RS standard in its API, the layer would nominally be a JAX-RS ContainerRequestFilter doing authentication/revalidation as a PreMatch operation which would either reject the request (if authentication fails) or pass the request to the underlying API method with the logged in user account info included. To mark API endpoints that require authentication and therefore filtering, a custom annotation can be used.

This new design would support Dataverse’s existing API authentication methods into such a filter (or another one(s) - filters can be stacked). This may be most straight-forward for the stateless SignedURL mechanism. The other mechanisms, which require Database lookups, could also be moved to a filter but would still have dependencies on internal Dataverse code.

This new design improves the testability and extensibility of the API authentication mechanisms.

(Specification extracted from Dataverse - SPA Authentication document)

What kind of user is the feature intended for?

API User, future SPA user

What inspired the request?

• Re-Architecture decisions for Dataverse Authentication and related Proof Of Concept (PoC) developed.
• Dataverse - SPA Authentication document

PoC repository link: https://github.com/GPortas/dataverse/tree/poc/api_security_filter

What existing behavior do you want changed?

AbstractApiBean's findUserOrDie method

Any brand new behavior do you want to add to Dataverse?

JAX-RS ContainerRequestFilter for authentication/revalidation

Any related open or closed issues to this feature request?

• As a developer, I'd like to use Bearer Token to send authenticated API requests #9229
• New API auth mechanism for SPA frontend requests to APIs (developers only for now) #9063

The API auth mechanisms requested in these issues should be part of the new filter-based mechanism.

[mreekie]

sizing:

• Filter will be sitting on top of only the API.
• Discussion: Previously we've discussed a filter approach but didn't go that way. Why? Filters were becoming a bottleneck. Maybe were a bottleneck? Maybe have improved since. Here we are not talking about java servlet filters, but rather JAX RS filters which are slightly different. Performance issues could be teased out in testing. Web.xml.authfilter - this was removed from the main xml a long time ago. Contains traces of our old way of doing it.
• This is related to: 9063 - add session API auth mechanism with feature flag #9290 which should be done before this.
• This may be too big to size correctly: 80

[GPortas]

As discussed in the daily meeting, I just reduced the size of this issue, from 80 to 33, as it is partially complete with this PR: #9303

I have transferred part of the original size to the PR.

@mreekie