Support external identity provider/authentication source

mih commented

2025-08-16 06:32:03 +00:00

(Migrated from github.com)

Presently, access token and user identity need to be hard-coded in the server config. With our next deployment, this means >100 users. This implies substantial maintenance load:

C&P errors for user ID and sending auth tokens
token updates for users that lost their token, or from mandatory invalidation

An external identity provider would help here. Below is a sketch of a possible scenario that would be very convenient for our use cases:

Only have the following in the config, for a particular (or all) collection(s):

Forgejo API root
identifier of a forgejo project
Forgejo API access token with appropriate permissions for that project

With an incoming request, the server checks whether an included token gives (a particular kind of) access to the configured project. If so, it grants access to the dump and perform the action, using the Forgejo user identity.

With this setup, users only need to be added once to the respective project, and from there on can generate and regenerate access tokens whenever they want or need.

Presently, access token and user identity need to be hard-coded in the server config. With our next deployment, this means >100 users. This implies substantial maintenance load: - C&P errors for user ID and sending auth tokens - token updates for users that lost their token, or from mandatory invalidation An external identity provider would help here. Below is a sketch of a possible scenario that would be very convenient for our use cases: Only have the following in the config, for a particular (or all) collection(s): - Forgejo API root - identifier of a forgejo project - Forgejo API access token with appropriate permissions for that project With an incoming request, the server checks whether an included token gives (a particular kind of) access to the configured project. If so, it grants access to the dump and perform the action, using the Forgejo user identity. With this setup, users only need to be added once to the respective project, and from there on can generate and regenerate access tokens whenever they want or need.

mih commented

2025-08-16 07:23:22 +00:00

(Migrated from github.com)

This appears to be straightforward to do:

curl -X 'GET' \
  'https://<forgejohost>/api/v1/repos/<owner>/<repo>' \
  -H 'accept: application/json' \
  -H 'Authorization: token <usertoken>'

Yield a JSON object with a permissions key:

{
  "permissions": {
    "admin": false,
    "push": true,
    "pull": true
  },
  ...
}

For a token that has no write permissions, push would be false.

This appears to be straightforward to do: ``` curl -X 'GET' \ 'https://<forgejohost>/api/v1/repos/<owner>/<repo>' \ -H 'accept: application/json' \ -H 'Authorization: token <usertoken>' ``` Yield a JSON object with a `permissions` key: ``` { "permissions": { "admin": false, "push": true, "pull": true }, ... } ``` For a token that has no write permissions, `push` would be `false`.

mih commented

2025-08-25 06:59:32 +00:00

(Migrated from github.com)

I just realized that, while better for all other goal, it would be easier for a TRR user if the auth check would go against the TRR gitlab instance API.

mih commented

2025-08-26 07:28:05 +00:00

(Migrated from github.com)

In order to place a complete submitted record, it needs two more bits of information that would need to be inferred from an API query of an identity provider:

submitter id
incoming areas label

Idea for a forgejo provider (should be doable in the same fashion for any git hoster).

submitter id

The https://<forgejohost>/api/v1/user endpoint provides a number of properties such as login, login_name, id, email, username. Any and all of these could be used as an identifier. It could become a configuration item, which of them to use for a particular deployment.

incoming area label

This could also be the submitter id chosen above, in case the shall be isolation of submitters. Alternatively, a submitter's team association could be used to determine an incoming label.

The https://<forgejohost>/api/v1/repos/<owner>/<repo>/teams endpoint lists all known teams for the reference repo. This information could be obtained once and remain cached (for some time).

From https://<forgejohost>/api/v1/user/teams it could now be determined, which team a user is part of (assuming one, and enforcing a 1:1 association). The name property of the matching team could be used as an incoming label.

In order to place a complete submitted record, it needs two more bits of information that would need to be inferred from an API query of an identity provider: - submitter id - incoming areas label Idea for a forgejo provider (should be doable in the same fashion for any git hoster). ### submitter id The `https://<forgejohost>/api/v1/user` endpoint provides a number of properties such as `login`, `login_name`, `id`, `email`, `username`. Any and all of these could be used as an identifier. It could become a configuration item, which of them to use for a particular deployment. ### incoming area label This could also be the submitter id chosen above, in case the shall be isolation of submitters. Alternatively, a submitter's team association could be used to determine an incoming label. The `https://<forgejohost>/api/v1/repos/<owner>/<repo>/teams` endpoint lists all known teams for the reference repo. This information could be obtained once and remain cached (for some time). From `https://<forgejohost>/api/v1/user/teams` it could now be determined, which team a user is part of (assuming one, and enforcing a 1:1 association). The `name` property of the matching team could be used as an incoming label.

christian-monch commented

2025-09-18 07:45:02 +00:00

(Migrated from github.com)

Addressed by PR #129, published in version 3.1.0

Rows
Columns

Support external identity provider/authentication source #102

submitter id

incoming area label