[LeeroyHannigan]

On a build with serde_json's preserve_order feature, a policy document, a trust policy or a set of session tags with two faults got a different error than on other builds, chosen by the order the request wrote them in.

Which builds

bson declares serde_json with preserve_order, and Cargo turns the feature on for every crate in a build that compiles the MongoDB backend crate. That is a --features mongodb binary, and also any build of the whole workspace, such as CI's cargo build --release and cargo test --workspace. There a parsed JSON map keeps its written order. A build of the extenddb package without the MongoDB backend (-p extenddb, as the Dockerfiles build it) sorts maps by name, so nothing changes there.

Change

Three loops over a parsed map stop at the first fault. Each now reads the map through by_name, a new helper in extenddb_auth::policy::document that returns the entries in name order:

• parse_conditions, for identity policies and permissions boundaries (through PolicyDocument::from_json). It reported the first unknown operator or malformed value, and its conditions came out in written order, so a later check that names the first bad condition, such as the CIDR check, differed too.
• validate_trust_condition, the trust policy check of CreateRole and the console, which reported the first invalid operator.
• session_tag_pairs, for object-form AssumeRole session tags. validate_iam_tags reports the first violation in these pairs, and duplicate_tag_key_ci names the later of two keys that differ only in case, so {"team": "a", "Team": "b"} reported Team on a preserve_order build and team elsewhere.

#780 proposed sorting the whole document after serde_json::from_str in PolicyDocument. That would not reach the other two loops: CreateRole's trust policy arrives through axum's Json extractor, and AssumeRole's session tags through serde_json::from_slice. The loops are where the order is read.

Tests

Each test runs both written orders:

• two_unknown_operators_report_the_first_in_name_order (policy document): a Condition with the operators BadA and BadB reports unknown operator: BadA.
• conditions_are_read_in_name_order (policy document): StringLike on aws:b and aws:a with Bool on aws:c gives the keys aws:c, aws:a, aws:b.
• validate_reports_the_first_bad_operator_in_name_order (trust policy): invalid Condition operator: BadA.
• session_tag_pairs_are_in_name_order: Team then team, and duplicate_tag_key_ci names team.

cargo test --workspace, which CI runs, builds these crates with preserve_order. Locally:

• cargo +1.88.0 test --locked -p extenddb-auth -p extenddb-server: 276 and 252 passed (plus 3 doc tests).
• The same with --features serde_json/preserve_order: the same counts passed. With the loops reading the maps directly, all four new tests fail there.
• cargo +1.97.0 fmt --all -- --check and cargo +1.97.0 clippy -p extenddb-auth -p extenddb-server --all-targets -- -D warnings: clean.
• git merge-tree against the open PRs that edit these files (fix: limit failed logins per source address and bound bcrypt verification #718, fix(auth): match Arn condition values as IAM does and reject at write the values IAM rejects #692, fix(auth): follow IAM's rules for policy variables in condition values #541, fix(auth): expand policy variables in Resource and NotResource #535): no conflict. fix(server): honor explicit Deny in role trust policies #402 already conflicts with main in assume_role.rs, with the same 12 blocks with or without this change.

IAM's and STS's answers to a request with two such faults were not measured; this change makes the builds agree with each other.

Fixes #780