Support external authenticaton source #129

Merged

christian-monch merged 14 commits from external-auth-source into master

2025-09-17 13:55:57 +00:00

christian-monch commented

2025-09-16 07:07:42 +00:00

(Migrated from github.com)

TODO

Add tests

Description

This PR adds the ability to use multiple authentication sources for user authentication and authorization. The supported sources are:

Configuration-file
Forgejo team membership and optionally team access to a reference repository

The PR adds the new optional, collection-level configuration key auth_sources to the configuration. The key contains a list of authentication source definitions. Authentication sources are tried in order until a token can be authenticated, or no more authentication sources are available. If the same authentication source is defined multiple times, only the first instance is used. The auth key is optional. If the key is not present, the configuration file is used as the sole authentication source.

The PR modifies the code to allow on-demand creation of token stores. This is necessary to support the authentication of tokens that are not defined a priori in the configuration.

Configuration authentication source

type: config

Forgejo authentication source

type: forgejo   # requires `user`-read and `organization`-read permissions on token
url: <api root, e.g., https://forgejo.example.com/api/v1>
organization: <organization name>
team: <team name>
label_type: <'team' or 'user'>
repository: <repository name>   # <-- optional, requires additional `repository`-read permissions on token

A token is successfully authenticated if all of the following hold:

The team exists in the organization
The user identified by the token is a member of the team
If a repository is provided, the team must have access to the repository

If no repository is provided, the token has to have at least read permissions for:

organization
user

If a repository is provided, the token has to have at least read permissions for:

repository

This is required to determine the teams that have access to the repository.

User ID

The user ID is the email of the user

Incoming label

If incoming_label_type is team, the incoming label will be: forgejo-team-<organization-name>-<team-name>.

If incoming_label_type is user, the incoming label will be forgejo-user-<user-login>.

Permissions

The permissions will be fetched from the unit repo.code of the team definition. The following mapping is applied:

`repo.code`	curated_read	incoming_read	incoming_write
`none`	`False`	`False`	`False`
`read`	`True`	`True`	`False`
`write`	`True`	`True`	`True`

Additional instructions:

Do NOT change or rewrite any text in quotes and citations, even if it contains grammar errors.
Do NOT change the meaning, intent, tone, or style of the text.
If the text is incomplete (truncated), do not invent meaning to complete it.

Since Forgejo API requests can be expensive, lookups of teams, organizations, and team's access to repositories are cached until the service is restarted.

### TODO - [x] Add tests ### Description This PR adds the ability to use multiple authentication sources for user authentication and authorization. The supported sources are: - Configuration-file - Forgejo team membership and optionally team access to a reference repository The PR adds the new optional, collection-level configuration key `auth_sources` to the configuration. The key contains a list of authentication source definitions. Authentication sources are tried in order until a token can be authenticated, or no more authentication sources are available. If the same authentication source is defined multiple times, only the first instance is used. The `auth` key is optional. If the key is not present, the configuration file is used as the sole authentication source. The PR modifies the code to allow on-demand creation of token stores. This is necessary to support the authentication of tokens that are not defined a priori in the configuration. ### Configuration authentication source ```yaml type: config ``` ### Forgejo authentication source ```yaml type: forgejo # requires `user`-read and `organization`-read permissions on token url: <api root, e.g., https://forgejo.example.com/api/v1> organization: <organization name> team: <team name> label_type: <'team' or 'user'> repository: <repository name> # <-- optional, requires additional `repository`-read permissions on token ``` A token is successfully authenticated if all of the following hold: 1. The team exists in the organization 2. The user identified by the token is a member of the team 3. If a repository is provided, the team must have access to the repository If no repository is provided, the token has to have at least read permissions for: - organization - user If a repository is provided, the token has to have at least read permissions for: - repository This is required to determine the teams that have access to the repository. #### User ID The user ID is the email of the user #### Incoming label If `incoming_label_type` is `team`, the incoming label will be: `forgejo-team-<organization-name>-<team-name>`. If `incoming_label_type` is `user`, the incoming label will be `forgejo-user-<user-login>`. #### Permissions The permissions will be fetched from the unit `repo.code` of the team definition. The following mapping is applied: | `repo.code` | curated_read | incoming_read | incoming_write | | ------------- | ------------- | ------------- | ------------- | | `none` | `False` | `False` | `False` | | `read` | `True` | `True` | `False` | | `write` | `True` | `True` | `True` | Additional instructions: - Do NOT change or rewrite any text in quotes and citations, even if it contains grammar errors. - Do NOT change the meaning, intent, tone, or style of the text. - If the text is incomplete (truncated), do not invent meaning to complete it. Since Forgejo API requests can be expensive, lookups of teams, organizations, and team's access to repositories are cached until the service is restarted.