| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Microsoft login (or Azure AD) nearly supports the OpenID Connect
protocol. With extensive configuration and some additional customization
of the values expected in the tokens, it will work with Zuul.
Add the necessary additional configuration and a HOWTO with the
procedure.
Change-Id: I445a0494796572762fbf78e580d7d6dd17be7239
|
|
|
|
|
|
|
|
| |
The release of pyjwt 2.0.0 changed the behavior of some functions, which
caused errors. Fix the errors, use pyjwt 2.0.0's better handling of JWKS,
and pin requirement to 2.X to avoid future potential API breaking changes.
Change-Id: Ibef736e0f635dfaf4477cc2a90a22665da9f1959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OIDC Authenticator can be configured to specify scope(s).
By default, use scopes "openid profile", the smallest subset of scopes
supported by all OpenID Connect Identity Providers.
Add a basic capability register for the web service. This is simply
meant to expose configuration details that can be public, so that
other services (namely zuul web-app) can access them through the REST
API.
Fix capability 'job_history' by setting it to True if a SQL driver is
active.
Change-Id: I6ec0338cc0f7c0756c0cb26d6e5b3732c3ca655c
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the RS256withJWKS driver with the simplified OpenIDConnect
driver. The new driver doesn't require the 'keys_url' parameter,
all needed parameters are fetched from the well-known config
endpoint inferred from the issuer_id.
Add a simple workflow test of the OpenIDConnect driver.
Change-Id: I4b0936a587918d6051a4206e20cad68577617e3d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Zuul admin can configure authenticators with an optional
"max_validity_time" field, which is the maximum age in seconds
for a valid authentication token. By default there is no
maximum age set for tokens, except the one deduced from
the token's "exp" claim.
If "max_validity" is set, tokens without an "iat" claim will
be rejected.
This is meant as an extra security to avoid accidentally issueing
very long lived tokens through the CLI.
The "skew" field can be used to mitigate clocks discrepancies
between Zuul and a JWT emitter.
Change-Id: I9351ca016b60050b5f3b3950b840d5f719e919ce
|
|
|
|
|
|
|
|
| |
Add an "authorize_user" RPC call allowing to test a set of claims
against the rules of a given tenant. Make zuul-web use this call
to authorize access to tenant-scoped privileged actions.
Change-Id: I50575f25b6db06f56b231bb47f8ad675febb9d82
|
|
A user with the right JSON Web Token (JWT) can trigger a autohold,
reenqueue or dequeue a buildset from the web API.
The Token is expected to include a key called "zuul.admin" that
contains a list of the tenants the user is allowed to perform
these actions on.
The Token must be passed as a bearer token in an Authorization header.
The Token is validated thanks to authenticator declarations in Zuul's
configuration file.
Change-Id: Ief9088812f44368f14234ddfa25ba872526b8735
|