9293 - New filter-based design for the API authentication mechanisms (1/2)

[GPortas]

What this PR does / why we need it:

This PR includes the refactoring changes for transitioning to the new filter-based design described in #9293 for the current API authentication mechanisms.

Due to the magnitude of the changes and in order not to overextend the revision work of this PR, I have decided to limit the scope of this PR in relation to issue #9293.

In particular, this PR covers the following points:

• The new authentication model is fully implemented, including all current authentication mechanisms (previously handled in the findUserOrDie method).
• Only Datasets API methods have been evolved to use the new filter-based design. The rest of the API resources (Files, Dataverses, etc) still use the old model (findUserOrDie).
• The findUserOrDie method has been marked as @Deprecated, as well as any other methods in the AbstractApiBean class related to the old auth design.

My idea for a next iteration is to evolve the rest of the API methods to use the new auth design so we can remove the old design logic (methods marked as @Deprecated in this PR).

Which issue(s) this PR closes:

Partially completes #9293 but does not close it.

Special notes for your reviewer:

Not yet

Suggestions on how to test this:

The behavior of the API must be the same as before, so in addition to the automated IT tests, curl calls to the API using different types of credentials can be used to test the different auth mechanisms.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

No

Is there a release notes update needed for this change?:

Not sure

Additional documentation:

Not yet / Not sure

[coveralls]

Coverage: 20.091% (+0.08%) from 20.009% when pulling fdab1b3 on GPortas:9293-filter-api-auth into 1aabf69 on IQSS:develop.

[mreekie]

Sizing: Still in Draft so no sizing yet.

[rtreacy]

examined all implementations in the auth package, new methods in AbstractApiBean such as getRequestUser(...) and getRequestAuthenticatedUserOrDie(...) which use ContainerRequestContext for parameters and are designed to replace findUserOrDie() and findAuthenticatedUserOrDie() and their use in DataSets API. Looks good

[kcondon]

@GPortas Please refresh from develop due to version numbers changing.

[GPortas]

@GPortas Please refresh from develop due to version numbers changing.

Done, @kcondon. Thanks!

[kcondon]

@GPortas So far, have tested 3 endpoints, gets JSON representation of dataset, publish dataset, create/get private url. They use getRequestUser and getRequestAuthenticatedUserOrDie.

They continue to work with api token and workflow token but so far do not work with signed url, returns {"status":"ERROR","message":"Bad signed URL"}. There is no server log error. It works on develop branch with the same exact signed url.

What I did to test signed url:
Pass Get JSON Representation of Dataset url into Request Signed URL endpoint for username who created the unpublished dataset, using api token of dataverseAdmin (super user) to execute the request.

Posted resulting url into a different browser, got metadata on develop branch, bad signed url on this pr.

[rtreacy]

Decoding issue causing signed url authentication to fail