bitwarden_pam/access_rules/
mod.rs

1//! PAM access rule CRUD operations.
2//!
3//! An *access rule* governs privileged access to a set of Bitwarden collections. Each rule bundles
4//! together:
5//!
6//! - **Conditions** ([`AccessCondition`]) that must be satisfied before access is granted - for
7//!   example requiring human approval or restricting access to an allow-list of CIDR ranges.
8//! - **Lease parameters** controlling how long access lasts once granted: a default and maximum
9//!   lease duration, whether a lease may be extended (and for how long), and whether a cipher may
10//!   have at most one active lease at a time.
11//! - The **collections** the rule governs.
12//!
13//! # Model layers
14//!
15//! - [`AccessRuleView`] - a decrypted view of a rule as returned by the server, including
16//!   server-owned fields such as `id`, `organization_id`, and creation/revision timestamps.
17//! - [`AccessRuleAddEditRequest`] - the input DTO for both creating and editing a rule. The same
18//!   shape is used for create and edit because the server derives immutable fields from the URL
19//!   (the organization and rule IDs) rather than the request body.
20//! - [`AccessCondition`] - the condition wire contract, shared by both of the above.
21//!
22//! [`AccessRulesClient`] is the entry point for all operations and is obtained from the
23//! [`PamClient`](crate::PamClient).
24//!
25//! # Conditions and forward compatibility
26//!
27//! [`AccessCondition`] mirrors the server's tagged wire format (`{"kind": "...", ...}`). The server
28//! is the source of truth for which condition kinds exist; a given SDK version only models the
29//! subset it understands. Any kind this SDK version doesn't recognize - or a recognized kind whose
30//! payload doesn't match the expected shape - is captured verbatim by [`AccessCondition::Unknown`]
31//! so that listing and enable/disable round-trips never destroy conditions the SDK can't interpret.
32//! See [`AccessCondition`] for the full round-trip contract and its known limitations.
33//!
34//! # Validation
35//!
36//! [`AccessRuleAddEditRequest`]s are validated locally by
37//! [`validate_request`](validate::validate_request) before being sent, so obviously-malformed
38//! requests fail fast with a typed [`AccessRuleValidationError`] instead of a round trip. This
39//! covers name length, lease-duration and extension consistency, the maximum condition count, and
40//! CIDR syntax. Unknown condition kinds are deliberately *not* validated locally - the server
41//! validates those. CIDR ranges are checked with [`is_valid_cidr`], which is intentionally stricter
42//! than the server to avoid client/server disagreement about which network a rule matches.
43
44mod client;
45mod conditions;
46mod error;
47mod models;
48mod validate;
49
50pub use client::AccessRulesClient;
51pub use conditions::AccessCondition;
52pub use error::AccessRuleError;
53pub use models::{AccessRuleAddEditRequest, AccessRuleView};
54pub use validate::{AccessRuleValidationError, is_valid_cidr};
bitwarden_pam/access_rules/mod.rs

bitwarden_pam/access_rules/
mod.rs
