Expand description
§Bitwarden Policies
Contains policy-related data types and structures used across the SDK, as well as business logic relating to policy enforcement.
§Introduction to policies
A Bitwarden enterprise policy is a setting (or collection of settings) that changes app behavior for an organizations’ members.
The policy domain is concerned with defining different policies and handling common enforcement decisions.
“Policy enforcement” is the process of determining whether a policy should affect app behavior for a specific user. For example:
- is this policy enabled?
- does the organization’s plan support policies?
- is the user exempt due to their role or status in the organization?
Policies often relate to other feature domains: for example, the Password Generator Policy affects how the password generator works. The policy domain cannot unilaterally affect other domains on its own - feature teams are responsible for consuming policy APIs in order to drive the behavior of their feature.
The goal of the policy domain is to handle common enforcement logic so that feature teams can consume the effective policy settings that they actually care about.
§Adding a new policy
-
Add your policy to
policy_type.rs. This must match the correspondingPolicyTypeenum definition on the server. This identifies your policy over the wire. -
Add your policy definition in a new module under
policies/, one per policy, alongside its data struct (for policies that carry data). This is a strongly typed representation of your policy for rust consumers. It must implement thePolicytrait, which defines enforcement behavior and any corresponding configuration data. Make sure to update thePolicyType.resolve_policymatch arm to return this struct. -
Add your policy to the
PolicyDataTypeenum. This is a type-erased representation of your policy for FFI consumers. The enum should wrap your configuration data, if any. Make sure to update yourPolicy.to_erasedimplementation to return this enum value.
§Consuming a policy
WARNING: these interfaces are not yet stable and should not be used.
Policy enforcement decisions are represented by EnforcedPolicy<P: Policy>. Its relevant properties
are:
enforced: whether the policy should be enforced against the user.data: the policy configuration data to be enforced, if any.
FFI interfaces return an EnforcedPolicyErased instead, which uses the PolicyDataType enum for
the combination of policy type + data (as generics are incompatible with the FFI). We recommend
using the native rust interfaces where possible to drive your feature’s behavior at the service
level.
The interfaces are:
get_enforced(get_enforced_erasedfor FFI): evaluate a specificPolicyfor a specific organization ID. Returns a singleEnforcedPolicy.get_all_enforced(get_all_enforced_erasedfor FFI): evaluate thePolicytype across all organizations. Returns a collection ofEnforcedPolicys, one for each organization.
Note that no interfaces return None/null: you will always recieve an enforcement decision, even if the policy should not be enforced.
Modules§
- models 🔒
- Data models for the policy domain.
- policies 🔒
- Concrete
Policyimplementations, one perPolicyType. - policy
- The
Policytrait and the enforcement machinery built on top of it. - policy_
client 🔒 PolicyClientand its associated extension trait.- policy_
type 🔒 - The
PolicyTypeenum. - uniffi_
support 🔒
Structs§
- Automatic
AppLog InPolicy Data - Configuration data for the Automatic App Log-in policy.
- Enforced
Policy Erased - The FFI-facing counterpart of the native
EnforcedPolicy, with its strongly-typeddataerased toPolicyDataTypeso it can cross the binding boundary. - Fill
Assist Policy Data - Configuration data for the Fill Assist policy.
- Master
Password Policy Data - The complexity requirements an organization enforces on members’ master passwords.
- Maximum
Vault Timeout Policy Data - Configuration data for the Maximum Vault Timeout policy.
- Organization
Data Ownership Policy Data - Configuration data for the Organization Data Ownership policy.
- Organization
User Notification Policy Data - Configuration data for the Organization User Notification policy: an organization-configured banner shown to members in their vault.
- Organization
User Policy Context - A minimal set of data for a user in an organization. This provides the context needed to evaluate the policies that are applied to the user.
- Password
Generator Policy Data - Configuration data for the Password Generator policy. Each field, when set, enforces a minimum or a required option on the member’s generator.
- Policy
Client - Client for policy domain operations.
- Policy
View - An organization policy in the raw data format that is sent over the FFI.
- Reset
Password Policy Data - Configuration data for the Account Recovery Administration policy.
- Send
Options Policy Data - Configuration data for the Send Options policy.
Enums§
- Password
Generator Type - The generator type the policy forces members to use, overriding their own preference.
- Policy
Data Type - Type-erased policy type + data for crossing the FFI boundary.
- Policy
Type - The type of an organization policy.
- Vault
Timeout Action - The action taken when the vault times out.
- Vault
Timeout Type - The kind of vault timeout the policy enforces.
Constants§
- UNIFFI_
META_ 🔒CONST_ NAMESPACE_ BITWARDEN_ POLICIES - Export namespace metadata.
Traits§
- Policies
Client Ext - Extension trait that adds a
policiesmethod to [Client].