admin API and superuser authorization · dev

Stream: dev

Topic: admin API and superuser authorization

luddaniel (Jun 06 2024 at 14:53):

Hey :) I would like to have a community view on this subject : https://github.com/IQSS/dataverse/pull/10612#issuecomment-2150667213

/api/admin API is blocked theoretically by settings :

curl -X PUT -d localhost-only http://localhost:8080/api/admin/settings/:BlockedApiPolicy
curl -X PUT -d "admin,builtin-users" http://localhost:8080/api/admin/settings/:BlockedApiEndpoints
meaning it requires to be in localhost to excecute /api/admin.

Some API need superuser API_TOKEN to work so my mind says :

under /api/admin must be placed every sensible endpoint that change/show global and technical configuration of Dataverse
under superuser credentials and not /api/admin must be placed every sensible endpoint that change/show the user rights/functionality of Dataverse

does this mean /api/admin should never require uperuser authorization ? Ex: should we remove this check https://github.com/IQSS/dataverse/blob/develop/src/main/java/edu/harvard/iq/dataverse/api/Admin.java#L617 ?

when should we combine both superuser credentials + /api/admin?

@Oliver Bertuch @Philip Durbin @Jérôme Roucou

Philip Durbin 🚀 (Jun 06 2024 at 15:00):

Right now we have a mix. It's quite inconsistent. We should probably pick one and stick with it.

Recently, in #10440, we introduced PUT /api/admin/superuser/$USERNAME. It does not require a superuser API token. It's used by the setup process to promote the first user (dataverseAdmin) into a superuser. It's a use case I think we want to keep, unless we decide on some other way to make dataverseAdmin a superuser.

luddaniel (Jun 06 2024 at 15:11):

I agree : for deployment usage (sh/ansible) we should avoid working with supersuper api key (or Burrito Key :peep:).
maybe the discussion should be around :BlockedApiPolicy setting :

localhost-only: Allow from localhost. DEFAULT combined with curl -X PUT -d "admin,builtin-users" http://localhost:8080/api/admin/settings/:BlockedApiEndpoints
unblock-key: Require a key defined in :BlockedApiKey.
drop: Disallow the blocked endpoints completely.

drop exists but should never be set in real env
unblock-key can be use when you reallllly want not only localhost usage

If that is OK, then we should remove every superadmin authorization check in /api/admin don't you think ?

Philip Durbin 🚀 (Jun 07 2024 at 11:46):

For consistency, you mean? I guess that's ok, to remove superuser checks under /api/admin.

Oliver Bertuch (Jun 07 2024 at 11:49):

I agree that we should start using a single approach and not keep going with this mix of stuff

Oliver Bertuch (Jun 07 2024 at 11:49):

IMHO this whole blocking thing can be made obsolete

Oliver Bertuch (Jun 07 2024 at 11:50):

We can use other means to authorize access to the admin API

Oliver Bertuch (Jun 07 2024 at 11:51):

IMHO it would be much more consistent if we allow usage of access tokens

Oliver Bertuch (Jun 07 2024 at 11:51):

Access tokens = OIDC / JWT based

Oliver Bertuch (Jun 07 2024 at 11:52):

Allowing provisioning of a pre-generated thing would enable bootstrapping via any framework etc

luddaniel (Jun 07 2024 at 12:54):

Philip Durbin said:

For consistency, you mean?

yes

Oliver Bertuch (Jun 07 2024 at 13:00):

Or do it the other way around: allow superusers access only and stop doing it in code manually but apply a proper auth filter

Philip Durbin 🚀 (Jun 07 2024 at 13:20):

In development it's more convenient to have /api/admin open (no API token required, let alone a superuser token), but it freaks me out a bit when it comes to production installations.

I most recently bumped into this when writing https://guides.dataverse.org/en/6.2/container/running/demo.html . If you look for "unblock", you'll see that I wrote about how to set the unblock-key. That way, you can change database setting securely.

Oliver Bertuch (Jun 07 2024 at 13:25):

If you're developing with containers, you need the unblock key anyway unkess you always go for running a curl command inside the app container

Oliver Bertuch (Jun 07 2024 at 13:26):

That's making it harder because it's less documented and non standardized

Oliver Bertuch (Jun 07 2024 at 13:26):

IMHO the default should be inversed

Oliver Bertuch (Jun 07 2024 at 13:26):

Make it require AA by default

Oliver Bertuch (Jun 07 2024 at 13:27):

But you can disable the filter using a feature flag

Philip Durbin 🚀 (Jun 07 2024 at 13:28):

Sure, as long as everything still works, especially having a superuser at installation time.

Oliver Bertuch (Jun 07 2024 at 13:29):

Also: if we ever want to have the SPA or other Frontends enable some admin UI, proper auth is the way to go

Oliver Bertuch (Jun 07 2024 at 13:29):

Same goes for client libs like pyDataverse

luddaniel (Jun 07 2024 at 13:42):

Oliver Bertuch said:

Or do it the other way around: allow superusers access only and stop doing it in code manually but apply a proper auth filter

If we do this, do we also remove everything about :BlockedApi?
Do you see side effect for users/admins ?

Oliver Bertuch (Jun 07 2024 at 13:44):

Classic installations probably are not often using the unblock key feature. If they do, they can migrate to the new auth scheme. It would probably be good to have a fallback thing in place for migration. Haven't thought much about it yet.

Oliver Bertuch (Jun 07 2024 at 13:45):

Containers users probably will be greatful to have a simpler option than the unblock key...

Oliver Bertuch (Jun 07 2024 at 13:45):

Creating a feature flag to disable the filter should be good enough for backward compatibility for localhost devs

luddaniel (Jun 07 2024 at 13:48):

I'm a bit scared (security) about 1 setting that allow everything. Or it should be something not in :Setting

Oliver Bertuch (Jun 07 2024 at 13:49):

No no I'm talking about a feature flag. Not a database setting. I agree that would be a bad idea

luddaniel (Jun 07 2024 at 13:50):

that does not ring a bell for me can you explain feature flag ?

Oliver Bertuch (Jun 07 2024 at 13:50):

https://guides.dataverse.org/en/latest/developers/configuration.html#adding-a-feature-flag

Oliver Bertuch (Jun 07 2024 at 13:51):

Maybe we should enable using both ways for some time, but deprecate the old ways. Log warnings etc

Philip Durbin 🚀 (Jun 07 2024 at 13:56):

Should we start a DEP? Is what we called them? :grinning: Like PEP or JEP or JSR. Dataverse Enhancement Proposals (DEPs).

luddaniel (Jun 07 2024 at 14:14):

As you prefere, hope it does fall into a forsaken box :face_with_peeking_eye:

Oliver Bertuch (Jun 07 2024 at 14:15):

Yes, a DEP would be good

Oliver Bertuch (Jun 07 2024 at 14:16):

We could use the template from @Ceilyn Boyd

Philip Durbin 🚀 (Jun 07 2024 at 15:13):

This one, sure: https://docs.google.com/document/d/1GnZiAyh2C6TQLlhKYD5m2JhtSGLg0ZwyiyF8M6y9cuw/edit?usp=sharing

Philip Durbin 🚀 (Jun 07 2024 at 15:14):

Private?

Philip Durbin 🚀 (Jun 07 2024 at 15:14):

Purpose
Background
Approach
  Plan
  Assessment
Participants
Assumptions and Dependencies
  Requirements and Resources
  Requirements
Resources
Timeline
Deliverables
Outcomes
Benefits
Risks
  Risk Mitigation

Last updated: Nov 01 2025 at 14:11 UTC