opendal-reqsign

reqsign-aws-v4 is the AWS SigV4 implementation inside the Apache OpenDAL reqsign workspace, providing the signing logic that authenticates requests to any AWS service that speaks SigV4 — S3, DynamoDB, Lambda, SQS, SNS, and more. Rather than bundling a full AWS SDK, it exposes a narrow, composable API: a RequestSigner that signs an http::Request’s parts against a service and region, paired with a DefaultCredentialProvider that walks the documented AWS credential chain (env, shared profile, SSO, web identity, process, ECS, IMDS).

Beyond baseline SigV4 signing, the crate handles the harder edges of AWS auth in practice: STS AssumeRole and AssumeRoleWithWebIdentity via a Granter abstraction, S3 Express One Zone session-token signing (with a toggle between the CreateSession and standard IAM/STS credential representations required by CopyObject, HeadBucket, and UploadPartCopy), and S3 Access Grants for exchanging a caller’s credential for a scoped temporary grant. Credential sources and HTTP/file I/O are pluggable through the shared reqsign-core traits, so the crate compiles for wasm32 targets by simply dropping the non-portable SSO and process providers.

What You Get

• RequestSigner - signs http::Request parts for any SigV4-speaking AWS service given a service name and region.
• DefaultCredentialProvider - the documented AWS default chain (env, profile, SSO, web identity, process, ECS, IMDS) with a builder to add, remove, or reorder slots.
• AssumeRoleGranter / AssumeRoleWithWebIdentityCredentialProvider - STS AssumeRole and WebIdentity exchange for temporary session credentials, including role-chaining duration limits.
• S3 Express session signing - dedicated CreateSession and standard-IAM credential representations for S3 Express One Zone, selectable per signer.
• S3AccessGrantsGranter - exchanges an existing credential for a scoped temporary credential via S3 Access Grants GetDataAccess.
• wasm32 support - the same API compiles for WebAssembly targets, with SSO and process credential sources conditionally excluded.

Common Use Cases

• Signing S3 requests from a custom HTTP client - object storage clients (like OpenDAL itself) that speak raw HTTP to S3 without pulling in the full AWS SDK.
• Authenticating DynamoDB or other SigV4 API calls - any service client that needs SigV4 headers or presigned query auth without SDK overhead.
• Running in Kubernetes with IRSA/WebIdentity - services that need to assume an IAM role via a projected service-account token rather than static keys.
• S3 Express One Zone integration - storage backends that need the CreateSession or IAM-credential signing path for the newer S3 Express endpoints.
• WASM-targeted storage clients - applications compiling to wasm32 that still need AWS request signing without process- or SSO-based credential sources.

Under The Hood

Architecture The crate is a thin, focused layer over reqsign-core’s trait system: sign_request.rs implements SignRequest for RequestSigner, which pulls the canonical request string, header canonicalization, and HMAC-SHA256 signing primitives from reqsign-aws-core and reqsign-core::hash, while credential resolution is delegated entirely to reqsign-aws-core’s DefaultCredentialProvider and re-exported through this crate’s lib.rs. Two Granter-based flows — assume_role.rs for STS AssumeRole and s3_access_grants.rs for S3 Access Grants — model one-shot, never-cached credential exchanges rather than long-lived providers, keeping the trust-transition semantics explicit (a granted session is the intersection of target-role permissions and any session policy, not a subset of the caller’s own permissions). A provide_credential/ submodule adds S3 Express session-token handling as a specialized credential provider so ordinary SigV4 signing and S3 Express signing share the same RequestSigner entry point with just a builder flag (with_standard_session_token) to switch representations.

Tech Stack Built on http for request types, bytes, quick-xml (serde-integrated) for parsing STS/XML responses, and log for tracing; it depends on sibling workspace crates reqsign-aws-core and reqsign-core for shared canonicalization and async traits rather than reimplementing them. The crate itself stays HTTP-client and async-runtime agnostic — dev-dependencies pull in reqsign-http-send-reqwest, reqsign-file-read-tokio, and tokio only for tests and examples, and criterion powers a dedicated signing benchmark (benches/aws.rs). Edition 2024, Rust 1.85 minimum, published as part of an Apache-governed Cargo workspace with lockstep sibling versions.

Code Quality Test coverage is extensive and organized by concern: tests/credential_providers/ has one file per credential source (env, profile, SSO, process, ECS, IMDS, assume-role, web-identity, Cognito, S3 Access Grants, S3 Express, static) plus Python-based mock servers under tests/mocks/ for the network-backed sources, and tests/signing/ covers standard, presigned, and special-character request signing against fixtures cross-checked against the official aws-sigv4 and aws-credential-types crates as dev-dependencies. CI runs a dedicated aws_v4.yml workflow with an always-on unit-test job plus additional jobs gated on network/secrets availability. Errors are typed through reqsign_core::Error/Result rather than swallowed, and public APIs carry doc comments with runnable examples.

What Makes It Unique Most AWS signing support in the Rust ecosystem comes bundled inside a full AWS SDK; this crate isolates just the SigV4 signing and credential-chain logic behind a small trait surface, which is what lets Apache OpenDAL support S3-compatible backends without depending on the AWS SDK’s transitive weight. Its S3 Express and S3 Access Grants support go beyond baseline SigV4 — few other standalone signing crates model the CreateSession-vs-IAM credential distinction or a scoped-grant exchange as first-class, cache-free Granter flows.