summaryrefslogtreecommitdiff
path: root/zuul/driver/auth
Commit message (Collapse)AuthorAgeFilesLines
* Add support for Microsoft loginJames E. Blair2022-02-111-9/+34
| | | | | | | | | | | 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
* Bump pyjwt to 2.0.0Matthieu Huin2021-01-141-23/+11
| | | | | | | | 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
* OIDCAuthenticator: add capabilities, scope optionMatthieu Huin2020-03-271-1/+16
| | | | | | | | | | | | | | | | 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
* JWT drivers: Deprecate RS256withJWKS, introduce OpenIDConnectMatthieu Huin2020-02-111-20/+63
| | | | | | | | | | | 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
* authentication config: add optional max_validity_time, skewMatthieu Huin2019-12-101-1/+30
| | | | | | | | | | | | | | | | | | 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
* Web: plug the authorization enginemhuin2019-07-301-2/+8
| | | | | | | | 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
* web: add tenant and project scoped, JWT-protected actionsMatthieu Huin2019-07-102-0/+197
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