neoeinstein/aliri

Web API access control for Rust

aliri's Issues

aliri_reqwest: `Bearer` auth scheme must be exactly cased

RFC 6750 Section 1.1 indicates:

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

In section 2.1, the RFC indicates the syntax for the credentials as:

b64token    = 1*( ALPHA / DIGIT /
                  "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

In no way does the RFC indicate that the scheme may be interpreted as case-insensitive. Right now aliri_reqwest produces credentials using bearer. This should be altered to Bearer to be compliant with the RFC.

Add interpretation of Cache-Control headers to background JWKS refresh

Right now, the automatic JWKS refresh from aliri_oauth2 will attempt to pass back received etag and last-modified header data to the JWKS endpoint in order to avoid unnecessary data transfer when the JWKS hasn't changed. We can also do some interpretation of the cache-control headers to ensure that we do not refresh faster than the max-age directive in that header. We will still want to use a static, passed in refresh time and use the maximum of those two values when deciding when to next refresh the JWKS.

We opt not to only use the max-age directive because that can lead to excessive refreshes on endpoints that do not often have changes, where the immediacy of those changes is not as important. This can lead to rate limiting of requests for distributed systems with many verifiers. Two scenarios appear to drive a desire for quick refreshes:

• The ability to phase in and activate a new signing token
• The ability to phase out and remove a signing token in use

For the first scenario, the delay between introducing a new signing token and beginning to use it for signing purposes should be at least the amount of time it takes all validators to have refreshed the JWKS. I am not convinced that a new signing token must be activated as soon as possible after it is introduced. Generally, a new token can be introduced minutes to hours in advance, so cleaving too tightly to the max-age is not necessary to achieve this objective.

For the second scenario, the delay before a signing key can be safely removed from the JWKS is limited by the maximum validity period of any token issued using that signing key. This has little to no relation to the max-age directive.

There may be other scenarios beyond those listed above. If you have any additional scenarios not called out above, add them as a comment to this issue.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>neoeinstein:semver/breaking/unstable)

Allow use of middlewares on token and JWKS refreshes

This can allow for the propagation and use of distributed tracing contexts through these operations.

RUSTSEC-2021-0141: dotenv is Unmaintained

dotenv is Unmaintained

Details
Status	unmaintained
Package	dotenv
Version	0.15.0
URL	dotenv-rs/dotenv#74
Date	2021-12-24

dotenv by description is meant to be used in development or testing only.

Using this in production may or may not be advisable.

Alternatives

The below may or may not be feasible alternative(s):

• dotenvy

See advisory page for additional details.

No option to use base claims

Now, when declaring an access policy by scope, it is not possible to get the fields of the standard implementation of BasicClaimsWithScope from the final structure without defining your own implementation of jwt::CoreClaims, namely those that are in jwt::BasicClaims.

Expected:

 scope_policy!(Profile / ProfileScope; "profile");

 #[get("/")]
 async fn endpoint(token: Profile) -> impl Responder {
     println!("Token subject: {}", token.claims().sub);
     HttpResponse::Ok()
 }

Actual:

#[derive(Clone, Debug, Deserialize)]
pub struct CustomClaims {
    iss: jwt::Issuer,
    aud: jwt::Audiences,
    sub: jwt::Subject,
    exp: Option<UnixTime>,
    nbf: Option<UnixTime>,
    scope: scope::Scope,
}

impl jwt::CoreClaims for CustomClaims {
    fn nbf(&self) -> Option<UnixTime> { self.nbf }
    fn exp(&self) -> Option<UnixTime> { self.exp }
    fn aud(&self) -> &jwt::Audiences { &self.aud }
    fn iss(&self) -> Option<&jwt::IssuerRef> { Some(&self.iss) }
    fn sub(&self) -> Option<&jwt::SubjectRef> { Some(&self.sub) }
}

impl scope::HasScope for CustomClaims {
    fn scope(&self) -> &scope::Scope { &self.scope }
}
 
 scope_policy!(Profile / ProfileScope(CustomClaims); "profile");

 #[get("/")]
 async fn endpoint(token: Profile) -> impl Responder {
     println!("Token subject: {}", token.claims().sub);
     HttpResponse::Ok()
 }

Whitelisting unscoped items

I'm using aliri-axum/aliri-tower, and can't find a way to "whitelist" a route, in order for it to stop checking for authentication. This is especially useful for a "login" route, but there's more than one route in my application that should be public to those unauthorized. However, even if I completely omit the scope from a handler's signature, it still returns aliri_tower::OnJwtError::on_missing_or_malformed.

In other words, I would like to be able to open some - but not all - routes to people without bearer tokens. Am I missing how to do this?

Add a license

In theory, even forks cannot be created for this project until it has a license

RUSTSEC-2020-0036: failure is officially deprecated/unmaintained

failure is officially deprecated/unmaintained

Details
Status	unmaintained
Package	failure
Version	0.1.8
URL	rust-lang-deprecated/failure#347
Date	2020-05-02

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

• anyhow
• eyre
• fehler
• snafu
• thiserror

See advisory page for additional details.

aliri_oauth2::Authority::new_from_url errors if an unknown algorithm is encountered

Even if multiple algorithms are offered, the deserialization of the response will fail if any unsupported algorithm is offered.
My Keycloak server provides both RS256 and RSA-OAEP algorithms.
Running

let authority =
        aliri_oauth2::Authority::new_from_url("https://example.com/auth/realms/master/protocol/openid-connect/certs", oauth_validator)
            .await?;

fails with

Error: error decoding response body: data did not match any variant of untagged enum Algorithm at line 1 column 90

with column 90 containing "alg": "RSA-OAEP"

RUSTSEC-2019-0031: spin is no longer actively maintained

spin is no longer actively maintained

Details
Status	unmaintained
Package	spin
Version	0.5.2
URL	mvdnes/spin-rs@7516c80
Date	2019-11-21

The author of the spin crate does not have time or interest to maintain it.

Consider the following alternatives (both of which support no_std):

• conquer-once
• lock_api (a subproject of parking_lot)
  • spinning_top spinlock crate built on lock_api

See advisory page for additional details.

RUSTSEC-2020-0056: stdweb is unmaintained

stdweb is unmaintained

Details
Status	unmaintained
Package	stdweb
Version	0.4.20
URL	koute/stdweb#403
Date	2020-05-04

The author of the stdweb crate is unresponsive.

Maintained alternatives:

• wasm-bindgen
• js-sys
• web-sys

See advisory page for additional details.

Decomposed and custom Header structs

Hi,

i couldn't find how to use custom Headers and decompose together. Using the naive approach

#[derive(Clone, Debug, serde::Serialize, serde::Deserialize)]
pub struct AbcHeaders {
    pub alg: Algorithm,
    pub jwk: Jwk,
    pub nonce: String,
    pub url: String
}

let decomp = token.decompose::<AbcHeaders>().unwrap();

didn't allow me to access the content of the AbcHeaders. Also implementing a trait for Decomposed does not work as self.header is inaccessible as its pub(crate).

Am i missing something obvious?

Unable to compile for Windows

When compiling for a Windows target (like x86_64-pc-windows-gnu), aliri_tokens/src/sources/file.rs:40:14 is flagged up as a compilation error, since .mode() is only implemented on Unix systems and therefore doesn't exist in OpenOptions for Windows targets.

Create middleware for `reqwest-middleware`

Allow inferring the token URL from an `Issuer`

For OIDC-compliant issuers, the token URL can be inferred from the Issuer using the well-known OIDC configuration endpoint.

RUSTSEC-2020-0048: Use-after-free in BodyStream due to lack of pinning

Use-after-free in BodyStream due to lack of pinning

Details
Package	actix-http
Version	1.0.1
URL	actix/actix-web#1321
Date	2020-01-24
Patched versions	>= 2.0.0-alpha.1

Affected versions of this crate did not require the buffer wrapped in BodyStream to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.

The flaw was corrected by making the trait MessageBody require Unpin
and making poll_next() function accept Pin<&mut Self> instead of &mut self.

See advisory page for additional details.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• fix(deps): update rust crate compact_str to 0.8.0

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): pin taiki-e/install-action action to 9fcebed

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/checkout digest to 692973e

Detected dependencies

cargo

aliri/Cargo.toml

• aliri_braid 0.4.0
• once_cell 1.19
• regex 1
• ring 0.17
• serde 1
• serde_json 1
• tracing 0.1
• thiserror 1
• openssl 0.10
• color-eyre 0.6
• tracing-test 0.2.4

aliri_actix/Cargo.toml

• actix-web 4
• futures 0.3
• once_cell 1.19
• serde 1
• thiserror 1
• tracing 0.1
• actix-rt 2
• actix-web 4
• color-eyre 0.6
• regex 1
• serde_json 1

aliri_axum/Cargo.toml

• axum-core 0.4.3
• http 1.1.0
• once_cell 1
• aliri_braid 0.4.0
• axum 0.7.5
• color-eyre 0.6.3
• reqwest 0.12.3
• serde 1.0.197
• serde_json 1
• time 0.3.36
• tokio 1
• tracing 0.1
• tracing-subscriber 0.3.18

aliri_base64/Cargo.toml

• base64 0.22
• serde 1
• serde 1
• serde_json 1

aliri_clock/Cargo.toml

• serde 1

aliri_macros/Cargo.toml

• serde 1

aliri_oauth2/Cargo.toml

• aliri_braid 0.4.0
• arc-swap 1.7
• compact_str 0.7.1
• reqwest 0.12
• serde 1
• thiserror 1
• tokio 1
• tracing 0.1.40
• openssl 0.10
• serde_json 1
• tokio 1

aliri_reqwest/Cargo.toml

• async-trait 0.1.79
• bytes 1.6.0
• http 1.1.0
• predicates 3.1.0
• reqwest 0.12.3
• reqwest-middleware 0.3.0
• tracing 0.1
• tokio 1

aliri_tokens/Cargo.toml

• aliri_braid 0.4.0
• async-trait 0.1.79
• rand 0.8.5
• reqwest 0.12
• serde 1
• serde_json 1
• thiserror 1
• tokio 1
• tracing 0.1.40
• clap 4.5.4
• color-eyre 0.6
• dotenvy 0.15.7
• tracing-subscriber 0.3
• tokio 1

aliri_tower/Cargo.toml

• bytes 1.6.0
• http 1.1
• http-body 1.0
• serde 1
• thiserror 1
• tracing 0.1
• tower-layer 0.3.2
• tower-http 0.5
• axum 0.7
• tokio 1

aliri_warp/Cargo.toml

• serde 1
• thiserror 1
• tracing 0.1
• warp 0.3
• color-eyre 0.6
• regex 1
• serde_json 1
• tokio 1

github-actions

.github/workflows/release-please.yml

• google-github-actions/release-please-action v4@e4dc86ba9405554aeba3c6bb2d169500e7d3b4ee
• actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
• dtolnay/rust-toolchain stable
• ubuntu 22.04

.github/workflows/rust.yml

• actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
• dtolnay/rust-toolchain nightly
• dtolnay/rust-toolchain stable
• Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
• actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
• dtolnay/rust-toolchain stable
• Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
• taiki-e/install-action nextest
• actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
• dtolnay/rust-toolchain miri
• Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84
• actions/checkout v4@a5ac7e51b41094c92402da3b24376905380afc29
• dtolnay/rust-toolchain stable
• Swatinem/rust-cache v2@23bce251a8cd2ffc3c1075eaa2367cf899916d84

---

• Check this box to trigger a request for Renovate to run again on this repository

Create convenience `Claims` extractor for `axum`

RUSTSEC-2021-0139: ansi_term is Unmaintained

ansi_term is Unmaintained

Details
Status	unmaintained
Package	ansi_term
Version	0.12.1
URL	ogham/rust-ansi-term#72
Date	2021-08-18

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

Allow creating an Authority from an `Issuer`

Right now, the creator of an Authority needs to know the JWKS URL for the issuing authority. However, for OIDC-compliant issuers, this can be inferred from the issuer itself. Add a creation method that pulls the JWKS URL from the well-known OIDC configuration endpoint (inferred from the issuer), and refreshes the configuration endpoint periodically to ensure that any updates to the JWKS URL are also tracked (this should be rare).

aliri: update to ring 0.17

aliri_oauth2 underspecifies features required from reqwest

When using Authority::new_from_url with the reqwest feature in aliri_oauth2, the feature by default does not enable any TLS. This can lead to errors such as

reqwest::Error {
  kind: Request,
  url: Url {
    scheme: "https",
    cannot_be_a_base: false,
    username: "",
    password: None,
    host: Some(Domain("example.com")),
    port: None,
    path: "/.well-known/jwks.json",
    query: None,
    fragment: None 
  },
  source: hyper::Error(Connect, "invalid URL, scheme is not http")
}

This error can be avoided by users specifying reqwest features to use in their own Cargo.toml, i.e.

reqwest = { version = "0.11", default_features = false, features = ["default-tls"] }

But this workaround is not immediately obvious. Users also need to make sure that the version they specify is in sync with aliri manually.

While this currently does allow users to choose the TLS library to use, a better solution might be to allow users to specify the type of TLS they would like supported through feature flags on aliri_oauth2, which can then be passed through to the reqwest feature flags inside the aliri-oauth2 Cargo.toml.

RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` instead

net2 crate has been deprecated; use socket2 instead

Details
Status	unmaintained
Package	net2
Version	0.2.34
URL	deprecrated/net2-rs@3350e38
Date	2020-05-01

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

JWK deserialization failures due to keys have near-opaque error messages

data did not match any variant of untagged enum MaybePrivate

The above error results from any JWK deserialization that fails to deserialize as a signer, but- unfortunately- this can be with correct JSON and semantically invalid key values. When this is the case, it's almost impossible to determine programmatically what field was the source of the issue.

It may be worth separating parsing and validation such that a pseudo-JWK can be deserialized, then use a separate error type in the process of validating its key values, turning it into a "true" JWK instance.

aliri_axum: support axum 0.7

Axum has had a number of api changes in 0.7 which make this crate incompatible.

RUSTSEC-2020-0049: Use-after-free in Framed due to lack of pinning

Use-after-free in Framed due to lack of pinning

Details
Package	actix-codec
Version	0.2.0
URL	actix/actix-net#91
Date	2020-01-30
Patched versions	>= 0.3.0-beta.1

Affected versions of this crate did not require the buffer wrapped in Framed to be pinned,
but treated it as if it had a fixed location in memory. This may result in a use-after-free.

The flaw was corrected by making the affected functions accept Pin<&mut Self> instead of &mut self.

See advisory page for additional details.

RSA256 implementation wrongfully requires exactly 2048 bit keys; should be >= 2048

See more info on why here: https://crypto.stackexchange.com/questions/95878/does-the-signature-length-of-rs256-depend-on-the-size-of-the-rsa-key-used-for-si

Is short, RSA256 means 256-byte hashes, not keys.