Skip to content

Conversation

@kuzaxak
Copy link

@kuzaxak kuzaxak commented Dec 3, 2025

Packeton currently supports a predefined list of OAuth providers (GitHub,
GitLab, Gitea, Bitbucket, Google). Organizations using identity providers
like Authentik, Keycloak, Azure AD, or Okta cannot integrate without
writing custom code.

This adds a generic OIDC provider that leverages OpenID Connect Discovery
to automatically configure endpoints from the issuer URL. The provider:

  • Fetches and caches OIDC discovery metadata (.well-known/openid-configuration)
  • Supports configurable claim mapping for non-standard providers
  • Maps OIDC groups/roles claims directly to Packeton roles, providing a
    simpler alternative to login_control_expression for role assignment
  • Falls back to default_roles when no role mapping matches

The role mapping feature addresses a common need where organizations want
to assign Packeton roles based on IdP group membership. Users in 'packeton-admins'
group can automatically receive ROLE_ADMIN, for example.

This is a login-only provider following the Google provider pattern,
as repository synchronization requires provider-specific APIs.

As suggested in #323 (comment)

Mirror repositories store metadata and zipballs on the local filesystem,
which prevents running Packeton in stateless container deployments. When
using S3 for regular package storage (`STORAGE_SOURCE=s3`), the `/data`
directory still accumulates mirror data that cannot be shared across
replicas.

This change extends the existing Flysystem-based S3 storage abstraction
to mirror repositories. Both metadata (packages.json, provider includes,
package JSON files) and distribution archives are now stored in S3 when
configured.

For zipball storage, hash-based path sharding is implemented to optimize
S3 performance. S3 partitions data by key prefix, so distributing files
across prefixes like `ab/cd/...` prevents hot spots when mirroring large
repositories like packagist.org.

Local caching is optional and configurable via `MIRROR_METADATA_CACHE_DIR`
and `MIRROR_DIST_CACHE_DIR` environment variables. When empty, all
operations go directly to S3 for fully stateless operation. When set to
`/tmp` paths, ephemeral caching improves read performance while
maintaining statelessness across container restarts.

The streaming fallback in `MirrorController` handles cases where local
cache writes fail, ensuring zipball downloads still work by streaming
directly from S3.
@kuzaxak kuzaxak requested a review from vtsykun as a code owner December 3, 2025 00:05
@kuzaxak
Copy link
Author

kuzaxak commented Dec 3, 2025

@wimwenigerkind Hey, here is reimplementation of your PR. I'm adding a support for Authentik OIDC, but that would work for any provider.

Packeton currently supports a predefined list of OAuth providers (GitHub,
GitLab, Gitea, Bitbucket, Google). Organizations using identity providers
like Authentik, Keycloak, Azure AD, or Okta cannot integrate without
writing custom code.

This adds a generic OIDC provider that leverages OpenID Connect Discovery
to automatically configure endpoints from the issuer URL. The provider:

- Fetches and caches OIDC discovery metadata (.well-known/openid-configuration)
- Supports configurable claim mapping for non-standard providers
- Maps OIDC groups/roles claims directly to Packeton roles, providing a
 simpler alternative to login_control_expression for role assignment
- Falls back to default_roles when no role mapping matches

The role mapping feature addresses a common need where organizations want
to assign Packeton roles based on IdP group membership. Users in 'packeton-admins'
group can automatically receive ROLE_ADMIN, for example.

This is a login-only provider following the Google provider pattern,
as repository synchronization requires provider-specific APIs.
For a container environment we can use ServiceAccount annotation to pass
assumed role credentials. Underlying package AsyncAWS already supports
it. TO make it easier for newcomers, I'm adding an explicit doc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant