Clean up Admin API calls requiring an API token

[scolapasta]

There are several Admin API calls that check for a token, when it is expected that these API will be protected on other ways (and many of the calls don't, so we don't have consistency).

Of the ones that do, some just check and don't do anything with the token - these should have that logic removed. Others need to the user to call a command - but we have a different way to get a default admin (though we likely should clean that up too).

[djbrooke]

• Some discussion about what gets moved out of admin and into other spots.

[landreev]

There has been some renewed interest in cleaning up Admin.java, so we may as well use this long lived issue to do that. We appreciate a report sent in by Caen Jones, @tsuretettee inquiring about the inconsistencies there, that has (re-)started the discussion. This is just another area where we've known all along things could be refactored, just never got around to it.

From an internal discussion, we had some semblance of a consensus that it should not take much of an effort to make all the methods uniform in how they handle auth (which is an overall good practice, aside from the security implications); and add an extra level of protection in the process.

We should discuss the details further. But the following approaches have been considered:

1. • The methods that need an admin AuthenticatedUser for the command engine could all rely on the same approach of just getting the default admin (via authSvc.getAdminUser(), like deleteTemplate() does now)
   • Plus we make everything under /api/admin require the secret key, under either unblock-key or localhost-only policy, adding an extra layer of protection on a prod. instance, should the proxy and/or firewall blocks, and the localhost filter check both fail.

2. Alternatively, we just make every method under /api/admin require a "normal" admin API token; instead of the dedicated, secret unblock key. This way the same extra level of protection will be added as in 1., and if any of the methods need to call the command engine, they will have an AuthenticatedUser in the crc.

If we decide to go with 2., I would suggest we make an extra effort to communicate that the API token auth does NOT mean it is ok to expose /api/admin to the world on a live/prod. system.

[poikilotherm]

From a container user perspective I can only agree - let's get rid of any misalignment.

Using an API Token by a Superuser sounds fine to me. It should be done using JAX-RS mechanisms to filter things properly though. Not some custom stuff that needs great care to be done the same everywhere. (So make use of @RolesAllowed on the whole class)

Also, I would very much appreciate enabling the use of OIDC bearer tokens for the Admin API. To give a bit more context: on K8s, it's pretty common to have a service account token available, generated by system. Adding the cluster itself as an OIDC provider means you can start using serviceAccountTokens as means to interact with the Dataverse backend from various jobs. Examples for such a job: syncing the Solr schema, deploying settings, creating users.

[pdurbin]

We talked about this during the containerization working group meeting the other day. See 03:24 in the recording.

@poikilotherm recommends allowing the use of OIDC with the admin APIs, especially for an installation like his that uses Kubernetes. We would need to revist our API blocking policy code and allow OIDC as an option. As we know, we'd also need to make the admin APIs consistent.

That said, there's much more detail in the video. We're happy to talk more at tech hours.