DIRACGrid / DIRACGrid/intercede

[Feature]: Credential/auth model (tokens, proxies, delegation)

Open
#17 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
3
Forks
3
PR merge metrics
No merged PRs in 30d

Description

## User Story

As a backend implementer and as the WMS consumer,
I want a decided credential model — how tokens and X.509 proxies are supplied to backends, renewed,
and scoped —
So that the ARC and HTCondor-CE backends can land without re-inventing DIRAC's `setProxy`/`setToken`
/`Tag: Token` conventions ad hoc.

## Feature Description

A draft **IC-ADR-003** now exists (`docs/adr/IC-ADR-003_credentials.md`, riding in PR #4 with the
other ADRs; this issue's implementation goes in a follow-up PR based on it): typed
immutable credentials (`BearerToken`/`X509Proxy` grouped in a `CredentialSet`), backend-declared
`CredentialRequirements` (kinds + audience + scopes — replaces `Tag: Token[:vo]` and
`audienceName`), and provider-based supply (`CredentialProvider.get(requirements)` — backend pulls
when near expiry; issuance/renewal policy stays consumer-side). This issue is: review/decide the
draft, then implement the `intercede.auth` types. The decision space it fixes:

- **Supply**: static credential objects vs a provider callback (today: caller calls
`setProxy`/`setToken` before each cycle and inspects `proxy.getRemainingSecs()` itself —
caller-driven renewal is the incumbent model and probably right for a stateless library).
- **Declaration**: how a backend/transport declares which credential kinds it accepts — replaces
DIRAC's `Tag: Token[:vo]` CS hack as the opt-in signal.
- **Audience/scoping**: typed replacement for `ce.audienceName` (ARC: `https://:`;
HTCondor-CE: `:9619`) so the caller can mint correctly-scoped tokens.
- **Materialisation helpers** (Tier C): write-token-to-file, write-proxy-to-file +
`X509_USER_PROXY`-style env injection for CLI-driven backends.
- **ARC delegation** (the hard case): create/sign/renew proxy delegations via CSR — decide whether
this is `ARCBackend`-internal (Tier C) or a reusable piece.
- **Boundary statement**: *payload* credential renewal (DIRAC `_monitorProxy`) is pilot-side, out
of scope — only *backend* auth is interCEde's.

## Definition of Done

- [ ] IC-ADR-003 reviewed and merged (draft already written; Draft → Accepted path like
ADR-001/002); its Open Issues (freshness margin, proxy representation/key material,
multi-VO, per-operation requirements) dispositioned
- [ ] `intercede.auth` types (Tier A) implemented + unit-tested; consumed by the `Transport`
protocol shape from #
- [ ] Token-vs-proxy selection expressible in backend config (registry request), no `Tag` strings
- [ ] Integration hook: ADR-002 auth config axis (`config/token/` vs `config/proxy/` per stack)
named as the validation path

## Alternatives Considered

- Backend-driven renewal (backend holds a refresh callback and renews itself) — moves policy into
the library and needs long-lived state; contradicts the stateless design.
- Keep DIRAC's `Tag: Token` opt-in — stringly-typed, CS-coupled; rejected.

## Additional Context

Evidence: `SiteDirector._setCredentials` (caller-driven renewal), `WMSUtilities.setPilotCredentials`
(same logic duplicated), AREX delegation machinery (`_prepareDelegation`/`_renewDelegation`),
HTCondorCE `_CONDOR_*` env-var token injection.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.